The optical drive did show up as a UEFI boot device with Ubuntu-saucy-64-mini. I don't know why it didn't recognize Vista64. I was also able to get it to recognize Mint 16 on USB Flash in UEFI only mode. The install appears to succeed and I can see the EFI boot partition.
On first boot after what appears to be a successful install, I get "A bootable device has not been detected", and the SSD is not listed as a bootable device in the visual BIOS.
With both enabled, installing with Ubuntu-saucy-64 mini.iso, I end up with an unbootable OS.
"Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key"
A rescue boot shows this GPT partitioning.
The BIOS will only see the mSATA SSD as a Legacy device. If you uncheck the Legacy option, it doesn't become a UEFI boot device.
I haven't had any better luck with the USB flash drives either. The Sandisk Extreme USB 3.0 drive locks the system up on boot, and USB 2.0 drives that I install the system with leave it in the same unbootable state. Any advice on a specific install method that is known to work?
What you're experiencing is very similar to me in my quest to install Ubuntu 12.04 on the D34010WYK. And sadly I don't think there's a specific method that can be used to get the install going, this seems to be a problem with the NUC and how it interacts with the mSATA drives in UEFI mode.
The reason why you're not able to boot in legacy mode is that when you install Linux from an Optical/USB device that is running under UEFI, it determines the system is running UEFI and it installs and configures the bootloader for that setup (hence seeing the UEFI boot partition) When you reboot, and the NUC is unable to read the drive in UEFI mode and you run it in Legacy....there is no bootloader configured for Legacy. I had the same thing happen to me with Ubuntu.
In the BIOS Boot section, there's an option to boot into an EFI shell. Enabling that drops into a very simplistic shell window, from which you can do some interacting with devices. When I dropped into that shell and accessed the drive (IIRC it was typing 'fd0:'), I could see the boot partition and the EFI directory. so I drilled down to where the efi bootloader resides (\EFI\ubuntu\grubx64.efi) and tried to run it. A few seconds later the Ubuntu desktop pops up, which tells me that the install worked...and I'm guessing you could probably do something very similar.
I then went and verified that I'm running off the sata drive, that it is running in EFI mode, and used efibootmgr to verify that there is an entry for the bootloader in it. What it seems to boil down to is that for some reason the NUC BIOS is not reading those entries properly and thus it isn't determining that the drive is UEFI capable. I'm hoping that somehow Intel can get beyond "well, it works in Legacy so just be happy that way" mentality and figure out what is going on here.
Message was edited by: Frank Zado *** UPDATE *** I was able to get the device recognized in the UEFI section of the BIOS, and boot directly into Linux even with Legacy support disabled. I'm not sure if this has something to do with the intricacies of how the NVRAM entries are being read, or some level of hardcoding in the NUC bios, but here's how it can be worked around: Following some of the advice from this link (http://www.rodsbooks.com/efi-bootloaders/installation.html), for trying to get the bootloader registered with efibootmgr, I started checking out the options under "several other possibilities", and found that putting the bootloader in the "default" position seemed to work. Ubuntu, and I'd bet a number of other flavors of Linux, put their loaders in specific locations (in mine it was EFI/ubuntu/grubx64.efi) relying on the entries in the NVRAM to be read for their locations. I used the Internal EFI shell to access my Ubuntu install (but this could also be done via USB stick or Live CD), made a BOOT directory under the EFI directory in the boot partition, copied the bootloader files there, renaming grubx64.efi to bootx64.efi, and rebooted (so basically EFI/ubuntu/grubx64.efi became EFI/BOOT/bootx64.efi). I expected to get dumped back into the shell but I popped right into the Ubuntu desktop. Rebooted and went into the bios and lo and behold, the SATA device was listed under UEFI boot devices! I disabled legacy support, saved and rebooted, and again came right up into the desktop. I don't think it is the "perfect" solution, but it does work.
Just tried the approach suggested of Frank Zad, with Ubuntu 13.10.
Thanks Frank. It works ok. The procedure i used:
1. Install from usb stick.
2. Then finished. Keep the usb stick connected and execute a shell.
3. mount /dev/sda1 /mnt
3. mkdir EFI/BOOT (BOOT dir at the same level as the ubuntu dir.).
4. cp EFI/ubuntu/* EFI/BOOT
5. no rename of grubx64.efi because the bootx64.efi existed.
6. no disable of legacy boot nessary. It automaticly starts on UEFI.
7. Remove usb stick and reboot.
I have also been experiencing difficulties getting the D34010WYK to recognise a drive (Mach Xtreme PCIE mSATA 120G SSD).
In Visual BIOS there are *no* entries in the UEFI section. In this respect there seems to be no difference between WY0018.BIO or WY0022.BIO
Could this be an issue with the drive hardware? Or is it just that an mSATA drive needs a EFI partition before it can be recognised? Because even with an EFI partition mine is not recognised by visualbios.
Naturally I can see the drive in the Legacy section, but that is of limited usefulness as after installing an OS it won't boot.
Just now I tried Hisper's very simple-looking instructions, but it didn't work. Admittedly I had already installed Kubuntu 13.10 earlier, and was simply re-booting from the USB stick using the "try kubuntu" live desktop option to perform the modifications to the prior-install. So maybe I'll try it immediately post-install... when I get the urge to reinstall it for what must be the 9th time now.
WHich brings me to an interesting, and possibly related/causal...phenomena..
I had done numerous installs of both kubuntu-13.10-desktop-amd64.iso in both legacy and UEFI modes, and had though it VERY odd that during these text based installs the network would report as not present, and the installer would complain appropriately, yet was a little stunned that it still downloaded content from the web and completed the installs.
Note: I do NOT have a WiFi / Bluetooth card installed. The NIC is the only net interface.
So I think what I'm seeing is the NIC not being recognised or initialized when booting in in legacy mode.
It often even shows in in the visualbios as "disconnected", when it isn't.
Also: why is there no 1000 Mbps listed? It's a GIGAbit NIC right?
I get the feeling that the LAN component is effectively broken in any mode that is not UEFI. Perhaps this is related to kubuntu 12.04 and 13.10, but since when does debian core not trivially recognise an Intel NIC or handle UEFI booting?
The whole "remotely-manageable-at-BIOS-level" thing, and the possibility of related code oversights in driver/BIOS/VisualBIOS are starting to look like the culprits.
I really hope something as simple as new firmware, or a conversation between debian and intel coders can make this device play nicely.
Also thanks for making firmware regressable. That's always theoretically good for tinkering and workarounds.
This is getting weird, so I'm just going to update a little:
I booted kubuntu-13.10-desktop-amd64.iso in order to reinstall it and follow Hispers 'fix'... and noticed that my NIC was now working... it showed as working in VisualBIOS just prior to botting the USB installer too. This is more expected behaviour than the 'not detected but works...sometimes" I was getting before.
So anyway I installed it. No problem.
On completion and reboot I decided to look at VisualBIOS to see if it recognised it as a UEFI drive now... nope.
So while I was there I figured I'd mitigate the lag-annoyance I get moving the cursor around by changing the default screen.So I changed the initial screen to open on "advanced - devices"....
Problem - When I boot now, all I get is:
"A bootable device has not been detected"
"Please refer to the product guide at... blah blah"
If I boot with F2, I see the Intel NUC screen, the list of boot options: F2, F7, F10, F12
... and it hangs on that screen.
So I assume by changing the default screen for VisualBIOS to open on I have killed VisualBIOS.
Fortunately the machine responds if I boot with F7 and F10 shows nothing to boot from..as per the threads' original no-UEFI drive issue... so I will try booting into the F7 BIOS flash utility and flashing the firmware... with WY0022.BIO this time - It was factory default WY0018.BIO before.
Flashing the BIOS had no effect whatsoever.
I can't F2 for VisualBIOS or it locks up, F7 to flash succeeds in writing the firmware but does nothing to get me back into VisualBIOS, and F10 shows an empty list.
If I have to try F12 for network boot I am officially going to consider screaming.
Betlog, you may want to try these suggestions:
- Use the power button menu to enter BIOS by holding the power button for about three seconds from power off state. (See page 62 of the PDF below).
- Remove the BIOS jumper in order to:
- Run a BIOS recovery
- Access BIOS configuration menu (pages 49-50).
I had already unsuccessfully tried both of these methods shortly after making my last post.
Today however I did get F2 entering VisualBIOS working again by using a different wired USB keyboard and holding the power button for 3 beeps. Then I set the home screen back to the default...and it starting to work again (let me push F2 at boot and enter VisualBIOS). Even works with the wireless keyboard again.
But all those issues are secondary obstacles to the real issue, and the question of this thread:
Why is UEFI booting such a difficulty?
Why is my mSATA drive not recognised as EFI...ever!? And why doesn't it AND the NIC work under a legacy boot.
I have been herding computers for a long time, and yet my experiences with this NUC are singularly frustrating.
I can't tell if its a hardware issue, but I really get the feeling it's not. Because of my bizarre experiences with VisualBIOS or the NIC working or not working, my gut tells me the firmware is the problem.
But I'm stumped.
What I did last week in order to get a bootable Kubuntu 12.04 (but no network) certainly isn't even getting me a bootable OS now.
Given that the NIC references a "UEFI Driver version" in VisualBIOS; I am thinking that if UEFI is disabled then the NIC is also effectively disabled, and that this behaviour may differ between the factory bios and the released files - WY0018.BIO, WY0021.BIO, WY0022.BIO.
Very, very tedious.
I could spend more money and buy an Intel mSATA to test if it's a drive compatibility issue. With no guarantee of success. This does however seem the most probable cause of UEFI not booting weirdness.
Can anyone please confirm what specific drives they have got booting *buntu?
I could try to find out if the firmware/hardware is faulty, and attempt to return it to the incredibly RMA-averse dealer I purchased it from, but nothing I have tested so far is particularly conclusive or repeatable. If returning it were simple I would have already done so, it's been such a hassle.
I could wait till Kubuntu 14.04 comes out and hope there is some UEFI magic that makes everything work. But that's a long time to wait, and my opportunity to find out if it's actually a firm/hardware issue will have totally closed by then.
Besides, I got 12.04 to boot sans NIC, and can't repeat even that limited success, and posters here say 13.10 works with some shoe-horning, yet I can't make that 'fix' work even once.
I'm at a loss for what to do next.
Similar to Hisper's, I have found another relatively simple solution:
1) In VisualBIOS - check that "Internal UEFI Shell" is checked/enabled and that "UEFI: Built-in EFI Shell" is an option in the list of UEFI bootable devices.
2) Boot the NUC and allow it to drop into the EFI shell prompt.
...assuming fs0: is the fat32 EFI partition that linux made...and it's in the same directory structure shown here...
3) type fs0:
4) type echo "fs0:\EFI\ubuntu\grubx64.efi" > fs0:\startup.nsh
5) type startup.nsh and you should boot into linux
From now on at boot you will briefly see the EFI shell before it autoexecutes startup.nsh
... not ideal.. but at least ubuntu can boot/reboot relatively naturally, even if your mSATA drive is never recognised as a UEFI device.
Hi, sorry I know it's of time has passed under the bridge for this one.
The EFI boot issue is a Debian issue, hence why other platforms built on Debian (eg: Ubuntu) have the issue.
Don't just enable legacy boot, but also disable EFI boot.
The perform a standard normal install and leave bios with legacy boot enabled. Once the install is complete you can re-enable EFI boot without issue, but Ubantu just uses the legacy method to boot.
Works on my NUC and SSD after experiencing the exact same issue.
Note: If your USB install media is UFI boot only, then you need to re-burn the ISO image with a proper utility.
Betlog, did you ever figure out the issue with the NIC not reporting gigabit speeds in the BIOS? I've run into the same issue that you described with being limited to 100mb/s. It will not auto negotiate to 1000mb/s or allow me to hard set it anywhere above 100mb/s. I've updated to the latest 0022 BIOS and enabled/disabled UEFI and it does not make a difference.
I have not tested the NIC further. I have never tested it's actual NIC speed. However if you say it cannot achieve full gigabit speeds I would not be even slightly surprised.
I am also on WY0022 now, but have spent numerous hours each fiddling with 18, 21 and 22.
To be honest I have had so many minor issues with this NUC that it has just been sitting on the shelf since my last post. Right now I'm hoping a new BIOS will correct issues I am having with it's CIR misreporting itself and therefore not working OOTB with lirc etc.
After working on the NUC further yesterday, I was able to get it to boot up with 1000mb/s speed. I’m not sure why it did not take the first time, but after updating to BIOS 0022, then rolling back to 0021, and again back to 0022 the NIC now boots and operates at gig speeds. It still does not give the ability to hard set that in the BIOS, but if its set for Auto-Negotiate, it will pick up gig connectivity.
BTW - not that it should matter but the BIOS update method that I've been using is the 'F7' boot option and .bio file - not the installable EXE.