to be clear, we are not asking for specific support for Linux flavours here. Of course Intel cannot guarantee to provide detailed device driver support and similar for all forms of operating system. There has to be a limit somewhere!
What we are demanding is that the NUC firmware correctly implements all of the relevant BIOS specifications as assumed by most operating systems (I guess ACPI these days and in this case - a standard defined by Intel in conjunction with Microsoft et al.).
It seems that at present there is some discrepancy between the expected and actual behaviour in the way that the NUC handles shutdown instructions from operating systems. Although this *may* be a problem with either Windows or Linux, the fact that both of these operating systems work as expected on hundreds of other platforms suggests that in this case the problem lies with the NUC.
From the cases we have reported, it is also clear that the NUC behaviour is very dependent on which devices are connected (e.g. USB, display, Ethernet), which further points to a problem with the NUC itself.
Given the length of time that this problem has been outstanding and the number of customer reports, it would seem fair, I think to ask for at least an acknowledgement of this problem, a statement of whether Intel plans to fix it or not along with an indicative (but non-binding) timescale. Do you agree?
The system is not restarting during shutdown due to a failure, but powers OFF and ON after 3 seconds.
This is nor related to OS! but to bios it self.
Mentioning you do not support validated/certified Operating systems. I will tell you this:
Millions of systems, or even Billions are runnin on Linux kernel, a kernel that is based on many systems.
Companies like: CentOS, Ubuntu or even open software which is using the official linux kernel, work properly on thousands of motherboards.
The fact this motherboard is having the same behaviour with Windows and Linux based systems, it shows clearly to be a bios failure, with ACPI Calls.
I tried to unload drivers on: IR and network before shutdown from a Linux box and i had the same behaviour.
The systems Shutsdown and then!!!! it starts again like it gets a Wake call.
This happens on windows and linux!
IF you reboot or restart the system, THEN! the system power led never goes OFF, which is a different behaviour.
I believe, intel is not givving time to fix the problem. Otherwise there would be a person with knowledge on this forum to analyse with us the issue.
We do not expect to have support on our Opensource operating systems, thanks god community has this. And If the bios was opensourced, someone would already have fixed it.
I would find it respectfull if we cut the mentions about windows or linux.
Firstly let me say that I am disappointed by Intel's response to this issue.
Why can't Intel's engineers figure out why their hardware won't shutdown? So far 4 months and counting?
Can an Intel engineer explain the hardware sequence of events required for a shutdown to occur and send this information to the Linux kernel team who I am sure will will either fix the issue if it is their fault, or point out to Intel's engineers where the problem is?
I have also logged a support call with Intel for this issue and I urge everyone else affected by this issue to do the same.
There's something weird with these boxes. I have two identical boxes running the same hardware and the same bios and settings on the same LAN. Both are also running the exact same OS. One works properly with WOL and one doesn't. They were both bought at the same time from the same retailer.
Extremely frustrating! Should we return all NUCs that don't work as 'faulty'?
....and here's something more unusual that may work to fix the WOL behaviour for some people. When I went through all the differences, I had an autostart.sh script on the working device (I'm running OpenELEC). The script is to enable the onboard IR in OpenELEC. When I put the script on the non-working NUC, magically it's WOL function worked correctly.
I am running a 4th gen i3-based NUC with bios v25. The file autostart.sh is in the /storage/.config directory. The contents of the script are:
modprobe -r nuvoton-cir
echo "auto" > /sys/bus/acpi/devices/NTN0530\:00/physical_node/resources
chmod +x /storage/.config/autostart.sh
In my BIOS, I have enabled the deep S4/S5 with wake-on-lan set as Normal Boot
Disabling WOL from S3/S4 also "fixes" the shutdown issue on my setup.
My main use of the NUC is as an HTPC with XBMC controlled via Yatse on smartphone/tablet.
At least I can shut it down now with Yatse instead of keeping the power button pushed for more than 5 secs.
But I also need the WOL feature to start it up!
Registered for updates and to say that I have recently purchased a D54250WYK, installed 30GB Intel mSATA and 8GB Kingston ram. Nothing else is plugged in during tests other than HDMI and Ethernet. Same instant restart problem. At first it was only Suspend (sleep) causing it, until I updated the BIOS to v25, where it started doing it for Shutdown as well.
I tried different settings in the power options. Following a recent post here, I disabled all options in the Power section first. Then enabled the 'Deep sleep S4/S5' checkbox - now the NUC behaves as expected. I am not sure if its going to S3 or lower, but I can boot from the onboard IR device with my remote luckily. Now that it works I am too scared to touch any of the options. I am not sure if WOL is set to Stay Off or Normal Boot, and can't check at this moment. I don't actually need WOL though.
It's a shame because the computer is really quite amazing. While it now works perfectly for my needs, this should not be as hard as it is. I am now using the latest nightly of OpenELEC as the operating system after testing a few. It certainly seems like a BIOS issue to me.
Unrelated but v25 caused my BIOS to display at the wrong resolution on my display. It's not being stretched out as far as I can tell, and is displaying 1:1.
For anyone who is experiencing these shutdown issues when Linux is installed, please consider trying the test BIOS at https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23826.
We have successfully tested this is our engineering lab but we'd like to get confirmation from NUC owners before we roll it into a production BIOS version for all NUCs.