UEFI Imaging with Debian 10 on Intel NUCs
-
Hi Everyone,
I’ve spent quite a bit of time searching about UEFI imaging. I’ve read that it works great, it doesn’t work great, it works with Windows, it does or doesn’t work with Linux. I can’t seem to find any definitive answers.
We’ve been imaging our NUCs for a few years now with fog and BIOS boot. We must migrate to UEFI for a new large client (5000 existing NUCs) we just got. We must remove windows from these NUCs and install Linux. I’ve successfully reinstalled Debian 10 using UEFI and captured an image. When I deploy the image on other NUCs, there’s not a single error but the device can’t find an operating system after reboot. I’ve even taken successfully imaged SSD drives from the master machine that boot in the master machine and put them in other devices and that SSD doesn’t boot in another device.
What am I missing and how do I solve this?
Thanks,
Stephen
-
UEFI booting doesn’t Magically, typically, detect the Boot partition.
UEFI uses NVRAM space to store the boot location.
Essentially, once you image the machine, you’ll need to tell the BIOS to look at the Hard Drive and select the boot file as appropriate.
Once you do that, I’ll bet you’ll have success with booting the machines.
This isn’t a FOG problem, persay.
-
In my experience if the UEFI firmware can see the boot partition it will list it in the uefi boot manager.
So if on partition 1 /efi/boot directory it finds the boot loader it will put that disk as bootable.
So I wonder how your original disk layout is created. Did it use LVM or are the partitions standard partitions? I would recommend regular partitions with the first partition as the efi boot partition.
On your Debian reference image, from a linux command prompt what do you get when you key in
fdisk -l /dev/sdaIf that throws an error look for the disk name inlsblkcommand then run the fdisk command. -
@george1421 Here ya go plus some additional info:
root@NUC:~# efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0001,0002,0003,0000
Boot0000* Windows Boot Manager
Boot0001* UEFI : LAN : IP6 Intel
Ethernet Connection (3) I218-LM
Boot0002* UEFI : LAN : IP4 Intel Ethernet Connection (3) I218-LM
Boot0003* UEFI : Built-in EFI Shellroot@NUC:~# fdisk -l /dev/sda
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk model: INTEL SSDSCKJW12
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: AE7EA9CB-3ECD-429B-AA65-D73F45898212Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 234441215 233390592 111.3G Linux filesystem
root@NUC:~#Oddly, Windows has never been on this drive. It’s not detecting debian nor is it showing up in the boot order list either in the BIOS or when pressing F10 for the boot menu. However, I was able to boot this device by going into the EFI shell and running grubx64.efi from /EFI/debian on /dev/sda1.
One note, this image was created on a nmve ssd. It has never caused a problem switching between nmve and non-nmve drives before and doesn’t change anything when imaging but I thought I’d throw that out there.
-
I may have solved this. More reading, specifically on Debian’s site concerning manually adding (thanks Tom) a new boot entry (adding details for anyone else needing this) with:
efibootmgr -c -d /dev/sda -p 1 -w -L debian -l ‘\EFI\debian\grubx64.efi’
then I deleted the old Windows boot entry (still don’t know how it got there) with:
efibootmgr -B -b 0000
Any advice for automatically detecting the EFI partition path in the post.download scripts so I can dynamically set EFI entries after imaging? Querying the list and cleaning it up automatically is straight forward.
With all this, I’m a little lost as to how I’d image a drive and move it to another computer without considerable expertise. The original plan was to image drives, ship them to remote sites and have someone less-technical swap them out. Is this even possible? I suppose we could run efibootmgr remotely before swapping out the drives. Sorry, thinking out loud.
Thank you both for the pointers.
Stephen
-
@sloeckle Well I can tell you that FOG doesn’t change any settings in the uefi menu, so that windows entry is probably from a previous install on that computer.
Now to your question about post download scripts. I have a tutorial that can be the starting point of your task.
The starting point could be here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed
If you start looking in this section of the post fog.custominstall
In the code you will see that I key off the
$osdifield. In this case I check to see if its one of the windows platforms. In your case you can use the same overall code flow/outline but switch case the linux code of 50. If you look a bit deeper into what is going on in the windows section we loop through the different disk partitions on the disk looking for the/Windowsdirectory on the partition. If its found then we exit the loop with the proper partition number.In your case you will loop through the partitions looking for
/EFIor/efiIf you find that directory (you could even be a bit more specific like/efi/bootthen you know what partition number the efi partition is. Yo u could also look at the partitions by the partition type but that could be a bit misleading because not every uefi partition is of type efi. Searching for the boot file path may be a bit more universal. For uefi the path don’t change. You just need to be mindful of the case.Once you have the identified partition then you can do the magic with the efibootmgr. You could be blindfully trusting and just replace the value in boot order 0000 or do a bit more coding to identify the values you don’t want to purge, or just insert your linux boot manager always at position 0 and set it to default. That will push all of the other entries down one position. I think that may be a messy approach especially if you reimage that target computer a number of times, but it would get the job done.
