I have bought NUC Kit 6CAYH, added SSD and 4GB Kingston RAM. PC is working fine, did memtest, run a lot of apps and everything worked fine. Then I moved the PC to production and NUC refuses to boot with Error: BIOS has detected unsuccessful post attempt(s)
I can not enter bios (even before the error appears), I can not answer Y neither N to the prompt, PC is frozen but ctrl+alt+del works... I tried replacing RAM, disconnecting SSD... Nothing helped until I removed ethernet cable. With ethernet cable removed, PC boots and even ethernet works if I plug it in after the PC boots.... Cable is connected to rather old edimax fast ethernet switch but the switch works fine for other PCs connected.
I will investigate more, but I just wanted to know if somebody had similar problem....
I do not recall any issues like this being posted previously (my AY has certainly not exhibited this). My gut reaction to symptoms would have been memory issue, not anything related to LAN.
I find it strange too - thats why I am asking here. I will look deeper into it as soon as I will not need the NUC in production... Exactly as you say, first gut reaction was RAM, then SSD cables and I was very suprised that ethernet cable is the culprit :-)
It doesn't say anywhere; have you tried replacing this Ethernet cable? Does it still happen with other cables? If it does, that might point to grounding/shorting issue...
I did not have a spare cable at hand but I will try it as soon as possible. However the strange thing is that the cable works just fine after POST, the device is communicating over that cable and it is only a few months old cable. Not to mention that I had other computer on the same cable without any problems before I purchased the NUC.
The whole situation is that I need the NUC to run on production site for cca 2 days and then I will have the whole month to experiment. I prepared the computer in my office but it was connected mostly over wifi and I do not remember if I did boot it with ethernet cable plugged in. Then I packed it up moved to the production site, connected to local ethernet (there is no wifi) and it did not start. So I suspected that the RAM or SSD did get loose during the transport... After some experimenting I pinpointed it to the ethernet cable being plugged in during POST (it does not matter if it is reboot or power up).
I will post more info after the event as I will have the oppurtunity to do more experiments....
So I had some time to experiment a little more. I tried multiple cables and multiple switches and I found out where the problem is.
The problem is not the cable nor the switch but the fact whether the network has DHCP or not.
So to summarize:
No ethernet connected: NUC boots
Ethernet connected to switch with no DHCP: post error
Connected the switch to the router with DHCP: NUC boots
BIOS Version: AYAPLCEL.86A.0060.2019.1527
Ah. Ok, now I understand. So, are you using Network Boot (i.e. using boot images on a Server)? If not, disable this feature completely in the BIOS:
This should avoid the issue you are having. I will bring up this issue with the support team.
Thanks for your reply. Disabling the network boot solves the issue but I still think this is a problem.
I am not using network boot for normal operation. But I do have network boot server on my office network with various diagnostic tools. In normal use the NUC has its own SSD with Windows 10 installed and runs single Digital Signage application. But on all my computers I have network boot enabled and set as last boot option. So in normal state the computer boots from its local storage and if that fails it does boot from network where I can boot linux and diagnose the issue. No other computer did have any problem with this configuration ever.
I am not sure if the network boot is in NUC enabled by default or if I enabled it but it has been set to boot from local SSD first.
So the exact behaviour with Network Boot enabled and set to last boot order is:
I appreciate the time you've taken to debug this issue. I have replicated it in our lab and have opened a bug report with the team. I will post any updates I have here, when I have them.
It is most-certainly only a workaround! As I said, it just avoids the issue occurring.
The BIOS team will most-definitely need to look into why this issue is occurring (Intel Customer Support will be passing the report along to them).
I apologize for the long time in getting back you, the good news is that this issue has been addressed and fixed in BIOS 65, here is where you can find the download: https://downloadcenter.intel.com/download/29291/BIOS-Update-AYAPLCEL-86A-?product=95062
Please give it a try and report back.