I've been using a linux based tool (https://github.com/milesp20/intel_nuc_led GitHub - milesp20/intel_nuc_led: Intel NUC7i[x]BN and NUC6CAY LED Control for Linux ) to change the Ring LED on the NUC6CAYH to different colors and modes.
I may have stumbled upon a situation where the NUC is unable to boot after the ring led has been set to fade instead of being on solid.
To create the problem:
- Set the ring led to "sw controlled" in the Visual Bios
- Boot into linux
- Load the driver and set the ring led to fade slowly in color white
- Reboot the NUC, it is completely stuck, the ring led is fading slowly white but the UEFI does not seem to go past POST or even offer any options to enter the setup menu
To temporary fix the problem, clear CMOS as suggested here: https://www.intel.com/content/www/us/en/support/articles/000005805/mini-pcs.html Clearing CMOS on Intel® NUC
- Plug AC power in
- 3 second power button trick to get into "safe mode"
- Enter setup, load defaults (F9) and save
This sets the ring led back to "power status" and makes the NUC bootable again.
Here comes the tricky part:
After booting successfully with the new BIOS settings I rebooted the NUC again and set the ring led back to "SW controlled", thinking it would be back to defaults (off) and boot.
But after saving and rebooting the NUC the ring led is fading slowly white again, I hoped the setting (and possibly bug) would be gone.
Now I am unable to ever set the ring LED back to "SW controlled" since it renders the NUC unbootable.
Could this be a BIOS issue?
I'm running the latest version: "AYAPLCEL.86A.0042.2017.1117.1918"
Thank you for joining the Intel® NUC Community. I am sorry to hear you are having issues with this matter.
From my end is hard to comment on your specific configuration since Intel does not test and validate Intel® NUC on Linux. It all indicates an issue with the software you are using. Is there any chance to test a different BIOS version? Perhaps: https://downloadcenter.intel.com/download/27088/BIOS-Update-AYAPLCEL-86A-?product=95062 Download BIOS Update [AYAPLCEL.86A]
Let me know the results.
Well, I've tried downgrading using the recovery BIOS procedure but I was unable to. So I've not been able to successfully downgrade the NUC. However this very much seems BIOS related (although maybe caused by the linux software), if calling a BIOS setting through ACPI renders the NUC unbootable surely this is a situation that the BIOS should be able to avoid ?
Thank you fort hat information Koen.
I noticed that there there is note for BIOS 42 that indicates the following: "Due to a security enhancement, it will not be possible to go to any BIOS earlier than BIOS 0042.". This is why you are unable to roll back the version, but let's try with a BIOS recovery and see if this address the issue.
Steps for the recovery: https://www.intel.com/content/www/us/en/support/articles/000005532/mini-pcs.html BIOS Recovery Update Instructions for Intel® NUC
BIOS 42: https://downloadcenter.intel.com/download/27348/BIOS-Update-AYAPLCEL-86A-?product=95062 Download BIOS Update [AYAPLCEL.86A]
The recovery method using a 0042 BIOS did work, in that the procedure does complete correctly with a 0042 BIOS file.
However it did not solve the problem, setting the RING LED to "SW control" still makes the NUC act the exact same way as before.
The RING LED still fades white and the NUC does not start to boot or initiate its display/keyboard.
We offer very limited support for Linux* based Operating Systems, we dont even provide specific drivers for it and usually recommend customers to visit https://01.org/ 01.org | Intel Open Source Technology Center but in this case you dont need drivers.
We do provide assistance to the same functionality you are making reference at (https://github.com/milesp20/intel_nuc_led GitHub - milesp20/intel_nuc_led: Intel NUC7i[x]BN and NUC6CAY LED Control for Linux ) but for Windows* based Systems, please see the following URL for further information: https://www.intel.com/content/www/us/en/support/articles/000023426/mini-pcs/intel-nuc-kits.html Using the WMI Interface to Program the Ring LED and Button LED
I would like to provide you with more insight about this but programming of the Ring LED and Button LED on Linux but it has not been validated or tested.
Thanks for your feedback. As I see it, it is probably not related to the fact that I'm using Linux but rather a possible bug in the BIOS.
Maybe the implementation of the tool I used triggered a situation in the BIOS that might not occur with Windows based implementations of changing the LED, but the unexpected behavior is displayed by the BIOS, not the OS in this case.
Either way (as I see it), if it renders the NUC unbootable because the BIOS is stuck at boot, probably there should be some extra code in the BIOS so that this situation is impossible.
Am I seeing this wrong?
We tested a couple of NUCs and set up the LED to SW Controlled in BIOS and this is not causing any boot issue. We also tested Windows* 10 without any problem.
I would recommend a BIOS recovery just to make sure that the system is back to factory defaults, here is the BIOS recovery file: https://downloadcenter.intel.com/download/27407/NUCs-BIOS-Update-AYAPLCEL-86A-?product=95062 Download BIOS Update [AYAPLCEL.86A] and the BIOS recovery procedure: https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/BIOS-Recovery-Update-Instruc... https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/BIOS-Recovery-Update-Instruc...
Please let me know if this helps,
Just for curiosity, I tested my NUC under Windows 10 environment, using NucLedController-v0.3
I was able to change several configurations as colour, transition, cycle colours and fade without any issue at any time.
I restarted, turn off and on, power outage and every time it was ok.
Just one note. I was able to use the configuration only running the application as Administrator.
Did you all test it as follows ?
- Set RING led to fade medium (I think)
- Don't shut down but remove power adapter
- Reconnect the power adapter
Also, at the same time I was testing with the option "Power State after pwr failure", I set it to "Power on".
I remember that I had issues getting into the safe mode of the UEFI menu due to this option.
Maybe the issue is a combination of this rarely used option?
@ Ronny G, I did try doing a BIOS recovery procedure (only the latest BIOS was an option, as suggested by Amy), which completed successfully but never solved the problem.
I fixed it!
Setting the PWR button also to SW controlled (not PWR status) magically fixed the boot issue and the NUC booted immediately after changing this.
Then I disabledthe blinking on the RING led and it continued booting properly.
How can we debug this situation and get a fix for it in the BIOS so that this never happens again?
I tried the NUC LED driver (http://nucblog.net/2017/05/linux-kernel-driver-for-nuc-led-control/ http://nucblog.net/2017/05/linux-kernel-driver-for-nuc-led-control/) on NUC7i7BNH, BIOS BNKBL357.86A.0063.2018.0413.1542 on the fresh installation of Ubuntu 18.04
And I received rather unexpected ext4 corruption in ~30 minutes while running docker, never seen things like that before. Auto fsck could not fix it, so I had to run it manually. Do you think it can also be caused by the LED driver?
I had run into the identical issue as the original poster:
NUC6CAYH, ring set to 'sw controlled', power button set to 'powerstate', state after power failure set to turn on. I was using the same nuc_led tool to set the state of the ring led and after updating to a recent bios the system would not post unless I set both the power and ring state to 'sw controlled'. The nuc_led module worked fine with the shipped bios and the no-post condition showed up sometime after bios 0042. The problem persisted at least through bios 0047 (2018-Jan-08).
I'm happy to report that after updating to bios 0049 (2018-May-08) and resetting the bios to factory defaults, I am once again able to set the ring led to 'SW Control', the power led to 'power state indicator', and the After Power Failure to 'Power On'. Manipulating the ring led in linux (centos7.5 in this case) with the nuc_led module no longer causes the system not to post on my nuc6cayh!