Do you already have found time to recover from fighting the demons which made it hard to get a Docker cluster up and running on Raspberry Pis? Hopefully – because the next crusade lies ahead of us! So let’s dive into the next adventure, watching our heroes – three greenhorn students – on their search for their Intel NUC’s missing boot target.
A new beginning:
Our story starts at Stuttgart Media University, where three brave students looked forward to putting their brand-new Intel NUC into operation. A NUC (Next Unit of Computing) is a small but fully functional PC developed by Intel. The model that was available to our three fellows was powered by a third-generation i3 processor as well as a 64 GB SSD. Great preconditions for flashing it with the newest Debian OS release and using it for cluster administration by making it the Shipyard host, they thought. Since the students had already figured out how to master Docker orchestration and even retained that in a previous blog post, making this work should not really be a great challenge. Far wrong …
.jpg)
The first rabbit punch:
After having flashed an USB drive with the latest Debian 8 release (“Jessie”), our three fellows launched the installer. A few minutes and configuration steps later, the installation process had succeeded and they removed the USB drive to boot the freshly installed OS from the NUC for the first time. However, they could hardly believe what they were seeing: The system asked them for the operating system they would like to boot, offering Linux and Windows. Something must have gone terribly wrong …
The enemy from the HdM network:
Finally, our fellows understood what had caused this strange behavior: Because the NUC has been connected to the network of the MI lecture room during the installation process, a configuration concerning this network must have imposed a custom bootloader on their NUC. Most likely, this mechanism was used to setup the room’s work stations in a comfortable manner. However, for our heroes this proved more as a barrier rather than being helpful.
As a consequence the students decided to re-run the Debain installation routine with the network cable unplugged. Again, they waited for the process to terminate and tried to boot the NUC for the second time, convinced that they will soon be able to get their hands dirty with Docker and Shipyard in an 64 bit environment. Although the disturbing dual bootloader has vanished and the NUC’s EFI started as expected, it welcomed our companions with a message that told them something like “unable to find boot target” …
Strike a light!
A fight to the finish:
One of the students suggested that probably the installation didn’t work as expected. So they once more plugged in the USB drive, repeating the Debian setup (meanwhile being able to do this blindfolded). Though, the same error raised up again. Actually doing the same steps a fourth and a fifth time didn’t lead to some kind of improvement.
Another approach which came to their minds was to resign the automatic installer and generate the required partitions by themselves. But not even that helped the companions to bring down this overpowering enemy. The situation seemed to be hopeless …
The wise men of Silicon Valley
Facing a bad defeat, our heroes determined to make use of their last resort. They have heard of two wise men of the Silicon Valley, Larry and Sergey, giving desperate people hope by overflooding them with possible answers to their questions. In fact, this led their attention on a prophecy of a guy called Andrew Cunningham which seemed to provide a solution to their issue. In short, this prophecy told them the following:
A bug has snuck inside the NUC’s EFI, which assumes to find a boot target called bootx64.efi inside the /EFI/BOOT folder on the corresponding boot partition. However, the Debian Linux distribution places a bootloader called grubx64.efi inside the /EFI/Debian directory (Caution: This is true for every Debian-based Linux distribution!). To bypass the NUC’s faulty behavior, the subsequent workaround can be applied:
# mount the ssd to the /mnt directory $ sudo mount /dev/sda1 /mnt # create the folder the NUC EFI expects $ sudo mkdir /mnt/EFI/BOOT # move the bootloader to the new directory $ sudo cp /mnt/EFI/debian/* /mnt/EFI/BOOT # rename the bootloader (according to NUC's EFI preferences) $ sudo mv /mnt/EFI/BOOT/grubx64.efi /mnt/EFI/BOOT/bootx64.efi
Our companions created a bootable Ubuntu USB drive and followed the steps the prophecy suggested them. Indeed, after having applied the changes everything worked well as soon as they gave the boot process another try.
Conclusion:
Finally, it has been a bug in the Intel NUC’s EFI implementation which brought heavy headache to our three heroes. But in the end, their strong will as well as a hint of the two wise men of the Silicon Valley helped them to master all the challenges on their road to getting Debian to work on a NUC.
And the moral of the story: Shit Failure happens, even at Intel 😉
Benjamin Binder, Jonathan Peter, Patrick Kleindienst
Image sources:
https://upload.wikimedia.org/wikipedia/commons/6/60/
Intel_NUC_Haswell_(case_rear_panel).jpg
Leave a Reply
You must be logged in to post a comment.