I've installed Lubuntu 17.10 on my new NUC5i3RYH and everything seems fine except the wired network. I can see the device using the usual Linux tools (ip, ifconfig, ethtool, lshw, etc.), assign an IP configuration to it and bring the device up. The ethtool utility reports that the device has a full-duplex Gigabit link to the switch (a Netgear GS108GE), the LEDs of the NUC's ethernet port and the Switch are lit thus saying the same as ethtool: the link is up. I can ping the device from the NUC itself, but however, I cannot send or receive packets from other machines in the network. What I've tried so far: checked the BIOS that the Ethernet device is activated (which it is), changed the switch port, the network cable, updated the BIOS (from RY0367.bio) and the intel network drivers (new version 188.8.131.52-NAPI). Still no success.
Do you have any advice what I could try before asking my vendor to exchange the device?
I understand you are facing an issue with the wired connection of your Intel® NUC.
Allow me to share with you that the Operating System you are using is not supported by the NUC you have. Please find that information in the following link: https://www.intel.com/content/www/us/en/support/articles/000005628/mini-pcs.html https://www.intel.com/content/www/us/en/support/articles/000005628/mini-pcs.html
If your NUC is having an IP address assigned and you are able to do ping to another device then the drivers are properly installed. In this case I will highly recommend you to look for support with the community of Lubuntu 17.10 to verify if there is a possible solution for this issue.
Please accept my apologies for any inconvenience.
It is correct that Lubuntu is neither officially supported by Intel, but on the page you have linked to there is Ubuntu listed as "Customer-reported operating systems". Lubuntu is based on Ubuntu and uses another desktop environment, but both use the same Linux kernel and kernel modules (one of which is the Intel-developed e1000e Linux kernel module driving the NUC's wired network device). So if Ubuntu works, Lubuntu should, too.
And then, I cannot ping another device on the network, but only the NUC's own local ip address. If I ping another device, I can see that the other device receives ICMP Echo Request packets and sends ICMP Echo Replies, but the NUC doesn't receive the replies. If i ping the NUC from another device, the NUC doesn't receive anything. Thus, the NUC can only send packets, but not receive them.
Intel does not officially support any Linux O/S release. The fact that it is a customer-indicated-working O/S means nothing. You need to work your issue through the Linux forums.
If it is a hardware issue, you need to demonstrate it on a supported Windows O/S.
Thank you for your reply. Indeed in the link I attached, on the section "Customer-reported operating systems" it shows a list of operating systems that are compatible with our Intel® NUC Boards and Kits by the owners of them nonetheless, as the script shows, Intel hasn't validated these operating systems. Please understand that the fact that Linux is open source can affect the configuration of its different versions like Ubuntu to Lubuntu, even if it is similar could not have the same configuration.
Furthermore, the fact that the NUC will show at least an IP address and the light of the Ethernet port turns on it means that the driver has been properly installed and the issue might be something else.
thanks for your reply.
You write, "Intel does not officially support any Linux O/S release."
True. But Intel is into the Linux community, if not part of it, developing and releasing drivers for its incredible hardware and, in fact, "not officially" advertising their Linux support. Please, don't get me wrong: I appreciate that and buy Intel hardware where- and whenever I can. But if the mainboard, the NIC, and the driver do all come from the same vendor, and, combined, have a malfunction: then I'm going to ask the vendor whether he knows about similar issues. Please excuse for annoying you.
You write: "The fact that it is a customer-indicated-working O/S means nothing."
Sorry, but I must contradict that. It means a lot if several heavily-related if not the very same "customer-indicated-working" operating systems work well on a specific hardware and, in this one special case, do not. What would you say, whom would you ask if you have a hardware device that is working on thousands of Windows 10 but not on your very own Windows Server 2016?
You write, "You need to work your issue through the Linux forums."
Been there, done that, got the t-shirt. ;-) In short: the same Linux kernel with the same kernel module drivers do work perfectly on the very same hardware with mostly the same operating system. Debian, Ubuntu, SuSE, Centos, Fedora, and DeadRat: they all work perfectly with that very same hardware.
And then, you write: "If it is a hardware issue, you need to demonstrate it on a supported Windows O/S."
Sorry, but I will definitely not buy Microsoft Windows just to prove that this is a hardware issue. ;-)
thank you for your reply and please excuse me for misspelling your name in my previous reply.
To make it short: I've asked my vendor to exchange the NUC, and he did. That new one works like a charm -- with the same Lubuntu GNU/Linux operating system on the very same Samsung 960 EVO -- and even with the same installation as before.
Being the hardware, the NIC, the operating system and the driver all the same, I have no other idea than that the old one has had a hardware failure.
Thanks and best wishes,
Let me properly rephrase that first statement: Intel does not officially support any Linux distro on the Intel NUC products.
As for the second and third statements, I stand by them. The fact that any one person was able to get a distro working does not mean that every person is going to be able to get that distro working and it does not mean that a different version of that distro is going to work either.
Look, what it comes down to is money. Each and every O/S that you validate and support costs you money. It takes dedicated resources, with the right knowledge, and a specific amount of time to verify that a particular O/S works. The dedicated resources cost money. The training of these dedicated resources costs money. The time to do the validation costs money. Even the place where you do the validation costs money. Worse, Linux development is so wishy-washy that you must consider each distro and, in some cases, each version of a distro, to be a separate O/S from a validation standpoint. At the end of the day, the cost of validating the supported O/Ss must be accounted for in the cost of the product. Raise the number of O/Ss supported and you raise the prices of these products; it is as simple as that. People have an expectation regarding what a product should cost and what they are willing to pay for it. They are not going to pay extra to see a O/S supported that they will never use. 95-96% of Intel NUC users exclusively want Windows. They are not willing to pay extra to see O/Ss that they will never use supported for the remaining 4-5%. Intel is not going eat this cost and/or sell the NUC products at a loss just so that they can say that they support some minimally-used O/S (or distro). Bottom line, the decision was made to validate and support only the Windows O/Ss. This isn't going to change while the numbers stay like this.