My DE3815TYKE was recently updated to v44 :TY0044.BIO
http://rzr.online.fr/p/?url=http://downloadmirror.intel.com/25040/eng/TY_0044_ReleaseNotes.pdf# %20http://downloadmirror.intel.com/25040/eng/TY_0044_ReleaseNotes.pdf%20# http://downloadmirror.intel.com/25040/eng/TY_0044_ReleaseNotes.pdf
Same file in TYBYT10H.86A.0044.BI.ZIP http://downloadmirror.intel.com/25040/eng/TYBYT10H.86A.0044.BI.ZIP http://downloadmirror.intel.com/25040/eng/TYBYT10H.86A.0044.BI.ZIP
And It boots fine, VisualBios displays : "Ver: 0ACCT014"
*But* then fail to load my GNU/Linux OS (Ethernet and keyboard not working) ...
More details on demand
I reported the problem at :
(normaly you should not be able to view it, but in case of I shared the reference)
I havent downgraded yet but wait for confirmation first ...
Because DE3815TYKHE reported serious issues :
Tell me if it's safe to downgrade to v24 to support headless usage :
/message/285968# 285968 https://communities.intel.com/message/285968# 285968
Which BIOS version to install on # DE3815TYKHE ?
Does the BIOS download feature used to work on that model too ?
Do you know other black magic procedures for NUC ?
Other hints :
From /inbox?objectType=2&objectID=218772 https://communities.intel.com/inbox?objectType=2&objectID=218772 "Try unplugging the NUC from the power outlet approx. 5 minutes, then power it back, then press the power bottom for 10seconds."
/message/318723# 318723 https://communities.intel.com/message/318723# 318723
More to come in this thread or maybe I should create a knowledge base's article somewhere ?
I finally downgraded from 44 to 43
There was an error message in the end suggesting about enabling or disabling fast boot ... and now usb boot , keyboard and ether are working again ...
I havent tested much , I'll wait TY0044.BIO ... and expect those 3 improvements :
- text only mode BIOS
- headless mode
- GPU reliability
Now, Here are some hints in French from CS :Veuillez effacer CMOS:http://www3.intel.com/cd/channel/reseller/emea/eng/membership/411560.htm http://www3.intel.com/cd/channel/reseller/emea/eng/membership/411560.htmhttp://www.intel.com/support/motherboards/desktop/sb/CS-034634.htm http://www.intel.com/support/motherboards/desktop/sb/CS-034634.htmMerci de mettre a jour la version du BIOS avec la methode recovery(comme expliqué a la page 2 et 3 du document suivant):http://downloadmirror.intel.com/22388/eng/BIOS%20Update%20Readme.pdf http://downloadmirror.intel.com/22388/eng/BIOS%20Update%20Readme.pdfBIOS:https://downloadcenter.intel.com/download/25040/BIOS-Update-TYBYT10H-86A https://downloadcenter.intel.com/download/25040/BIOS-Update-TYBYT10H-86A
Somewhat the same symptom here, but different end result. Brand new NUC, it was on BIOS 0019. After flashing to 0044 it would no longer boot Linux from the eMMC, it was unable to find the filesystems. The only other BIOS I was able to get onto it was 0041, and I had to do that via recovery with the jumper off, it does seem to be functional again. However now I cannot update it to 0043 or 0044 via any method.
Let me know if you verified after the BIOS update, if the 4GB eMMC option is enable in the BIOS setup:
Devices and Peripherals>OnboardDevices>Onboard Device Configuration> 4GB eMMc Built-in Storage
Also, please check the OS selection.
Boot>Boot Configuration>UEFI BOOT>OS selection
I created a lab using the latest BIOS version 0044 and Debian 8, no issues.
In regards to remote access; please follow the steps below:
http://www.intel.com/support/motherboards/desktop/sb/CS-034652.htm Intel® NUC Boards and Kits — Remote Access to Intel® NUCs
I received a warranty replacement NUC today. Same as my original, the board is marked AA H26998-401, chassis marked SA H27002-400. Mike I have to wonder if you are testing with this same hardware, as the behavior certainly is different.
The replacement unit which arrived with BIOS 0019 at least now allows me to flash back and forth between 0043 and 0044, which has allowed me to collect more info.
The OS I have been running on this system is Openmediavault 2.1, which is based on Debian 7. Just like my original unit, I can have a fully functional system, flash it to 0044 and it will now fail to boot due to being unable to locate the eMMC as seen in the attached photo. Also although the keyboard is functional in BIOS and GRUB, once the kernel has attempted to boot, the keyboard is now nonfunctional. Booting to the installation CD in 0044 also results in a loss of keyboard functionality after the bootloader, so an install couldn't even be done there. Flashing back to 0043 returns the system to proper behavior. Yes, the eMMC has been enabled and the OS has been set to Linux in the BIOS throughout all of my testing.
I then did an installation of Debian 8.2 while using 0043. After flashing to 0044, this OS did boot to a login prompt, however the keyboard was nonfunctional. Also booting to the installation CD resulted in no keyboard functionality after the bootloader. Returning to 0043 restored keyboard functionality.
Some further experimentation:
Booting a Windows 10 DVD without changing any of the BIOS settings from what they are for Linux, also results in no keyboard with 0044, but a functional keyboard with 0043.
The previous Debian 82 installation with BIOS 0044, change the BIOS settings to Windows 8.x with the eMMC enabled, and not only does it boot to a login prompt, but the keyboard now works.
I think all of this takes Linux out of the picture and shows that it isn't really a Linux problem, but a BIOS 0044 problem, WHEN it is configured for Linux.
Considering how multiple customers in multiple threads on here are reporting systems which will not boot and/or will not respond to keyboard input, I would think this would be considered a severity one defect and this BIOS update would be pulled from the website so that other customers do not experience this downtime.
Next issue, headless boot. This is not the first time I've seen a response from Intel linking to info about OS drivers and "remote access". This is not the concern, at all. The concern can't possibly have anything to do with the OS. If a monitor is not attached, the system flat out will not complete POST. Now, I can attach one, and as soon as "Intel NUC" flashes on the screen I can yank the cable out and the system will go on and boot the OS as normal. But if no monitor cable is attached, whether it is a warm or a cold boot, the system will not complete POST, so it never makes any attempt whatsoever to boot the OS. This is also a serious product defect.
If I can provide any further info just let me know.
In regards the issue with the keyboard and mouse (not recognized), get into the BIOS and disable XHCI mode. Advanced>Devices and Peripherals>USB>USB Configuration. Legacy Boot Priority needs to be enable.
Devices with USB2.0 will be recognized properly. Please use the USB ports from the back panel.
In regards headless issue, as a workaround keep plugged the video cable to the NUC and unplug the cable from the monitor and try to get into the NUC remotely.
I have only had legacy boot enabled all along. Yes, if XHCI is disabled I do have keyboard functionality with BIOS 0044. Loss of USB 3.0 would not be acceptable though.
Plugging in just a video cable does nothing to get the system to boot without a monitor.
The front panel USB port will work at USB3.0 if you have enable UEFI boot only. The troubleshooting above works while you are installing the operating system; after installing the operating system and drivers it is possible to enable XHCI.
In regards to remote access, please provide me with the name and version of the remote access software that you are using.
Mike, the asking about remote access software repeatedly is getting old. It doesn't matter what I am using when the system won't boot, in fact it doesn't even matter what operating system. I want the system to boot up with no monitor attached, and it won't even complete POST to attempt that.
And as for the all the try this, try that steps being given to get me to change some BIOS settings, it seems to be repeatedly overlooked that booting some OS, and keyboard in what appears to be all OS were just fine, until 0044. That BIOS release broke things that weren't broken before. I'm not looking for something I can change in order to work around 0044's shortcomings, I want everything working again, like it did in 0043 and prior.
This Intel® NUC Kit is still under support, so we might have a newer BIOS version soon. May I know the application that you want to run without display? I will pass this information to our engineers.
I want it to boot Linux for general usage, without a display or any kind of display cable attached, just like every PC I've owned.for the past couple of decades would do. There is no specific application which I want to use that has anything to do with the display. I will be logged into the system via SSH and running command line applications/utilities.
FWIW, rolling this system all the way back to BIOS 0024 will allow it to boot with no monitor cable attached. So this was working at one time, but has been broken for about the last year and a half now.
Can you try BIOS 46?
46 is the newest BIOS and it is supposed to fix this issue, here is the URL: https://downloadcenter.intel.com/download/25496/BIOS-Update-TYBYT10H-86A- Download BIOS Update [TYBYT10H.86A]
Results after some quick testing of the 0046 release today.
1. Defect that appears to be resolved - The previous 0044 release had a defect where the keyboard was non functional after booting the OS, if the BIOS was configured for a Linux OS. It didn't matter if it was actually booting Linux, it could even be Windows and have the same issue. Disabling XHCI allowed normal keyboard operation, however loss of USB 3.0 is unacceptable. With BIOS 0046 I was able to boot a Linux OS with the BIOS settings configured for such, and the keyboard continued to function.
2. New defect - When issuing a halt from the command line, the Linux OS shuts down, however the NUC does not power down. This is a great inconvenience, as it then requires manual intervention with the power switch to turn the system off and then back on. If BIOS 0043 or 0024 are used, once the Linux OS shuts down, the NUC powers down as would be expected, which then allows it to be easily powered back up remotely when needed via WOL.
3. Defect which has not been resolved - This model NUC will not complete POST unless a monitor is connected. This of course prevents any headless boot. The last BIOS release where this defect was not present was 0024. Multiple customers have posted about it in this forum multiple times beginning soon after the release of version 0030: https://communities.intel.com/thread/54144 https://communities.intel.com/thread/54144 Now after 15 months and 9 more BIOS releases, this defect is STILL present. This gives the appearance that customer field defects are not being used to create new test cases in the BIOS test plans, so the same old defect ships, over and over.
We are still working on your issues. The newest BIOS version solved USB 3.0 problems. Additionally for Microsoft® Windows 7 and USB 3.0 we created a software patch to solve the issue. It is not necessary to change the settings of XHCI in the BIOS.
More information at Installing Windows 7* on Computers with USB 3.0
The engineers are still verifying the bugs on the latest BIOS versions; We will try to get a solution as soon as possible.
By any chance, are the units exhibiting this behavior "customized units" or rebranded units?
My concern is that I have been trying to replicate this issue with no luck and I wonder if there is anything that I am missing.
Let me know if you already tested your NUC with latest BIOS version 0046.