@Tom-Elliott @george1421

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

Another option would be to configure your fog server to be a router, serving ip addresses only for a new subnet behind the fog server’s second NIC via a switch dedicated to imaging. We do this in our primary imaging lab. Let me know if this appeals to you and I’ll go into greater detail.

@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 Shell

root@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-D73F45898212

Device 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.

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

Hey Everyone,

Posting this to help anyone else out with this box. I have NUC 6i3SYH, pretty much the same box. Using 1.2.0 with old kernels, I could not upload an image to fog. Upgrading the kernels manually with George’s suggestion unfortunately did not help me either. I got a little further but would timeout when attempting to mount the remote NFS volume. The only thing that worked was to upgrade to trunk. Not only do I have all the new features, I can image these 6th gen NUCs!

Thanks for starting the thread. It helped me greatly!

Stephen