UEFI OS boot loader auto-detection

device
#1

We have found that some hardware using UEFI doesn’t auto-detect OS boot loaders. This makes UC20 installation not simple on those devices, as they to make them boot you have add the boot entries in the UEFI firmware manually [ or via some automation that must be maintained ].

Comparing this to traditional Ubuntu install, which I believe creates the boot entries on OS install, it’s a bit of a drawback.

This auto-detection works fine on Intel NUCs, but on some Fujitsu devices we tested it does not.

I would like to see all vendors do at least make this auto-detection behaviour configurable, but the reality is they all do things differently.

Have other people run into similar issues ?

Cheers,
Just

#2

Do I understand correctly that the installation does not start at all because you need to manually add an OS entry?

#3

From the look of it, we’re relying on the firmware booting the EFI/boot/bootx64.efi boot loader from the ESP. This is the path used to perform a UEFI boot off removable media. I don’t think there any guarantee that it will work for fixed media, although many UEFI firmwares support it, since it’s a useful way to bootstrap a system.

Presumably @jocado has encountered a system which doesn’t support this.

#4

That’s correct, the firmware on these devices only seems check for EFI/boot/bootx64.efi on removable media, not fixed disk paths. So, it only boots once we’ve added the entry using the UEFI executable.

We have raise it with the vendor in this case, and they may accommodate us, but I can see various other vendors doing the same thing. It seems to be an implementation detail, rather than part of any standard.

It just struck me as a bit of a short-coming [ vs an OS that installs itself via bootable media and add the entry in the firmware itself ] , and something to watch out for.

Of course, if people are working with hardware vendors or suppliers to get the UC image written in a factory then they will probably also ensure the firmware is setup correctly, in which case it won’t be a problem.

Cheers,
Just

#5

Perhaps we need to do equivalent of grub-install adding OS entries to the EFI NVRAM during install. That is provided, one can actually boot the installer in the first place.

Edit: had a quick look at grub-install. This block is responsible for adding for registering a new OS with EFI firmware: https://github.com/rhboot/grub2/blob/e7b8856f8be3292afdb38d2e8c70ad8d62a61e10/grub-core/osdep/unix/platform.c#L135-L177 It’s actually a direct call to efibootmgr which is something we could easily do if needed.

#6

Yes, but it’s chicken and egg type scenario.

The UC20 install relies on booting the image that has been written to a fixed disk, but the UEFI firmware is not auto-detecting in this case, so there is no boot and no install without intervention outside of UC20.

Cheers,
Just

#7

What I’m thinking about is a one time thing. Enable booting from removable devices, install proceeds and registers the system from the recovery partition. Upon successful completion one can go and disable removable device boot. Since we chainload grubs into run mode, only the loader from the recovery system needs to be registered.

#8

@mborzecki

Perhasp I’m missing something, but the installation procedure for UC20 is to write the UC20 image to the fixed disk, so not a removable device. So how will enabling boot from removable devices help ?

With UC20, if you write the image to a removable device, like a USB Flash, the installation happens to the USB Flash and not the fixed disk. At least, that’s what happen on our test NUCs.

Cheers,
Just

#9

For a device like this, you’d need to boot off some other removable media that then sets the boot option variables in the NVRAM. Once the removable media has set up the boot variables, the system should boot off the flashed fixed disk.

This seems like the kind of thing that could be done entirely from the UEFI environment, so I kind of wonder if anyone has built such a tool already? You’d need something like it if you were flashing a Windows image on such a machine and needed it to boot.

#10

Sorry I misread your comment about the firmware ignoring EFI/boot/bootx64.efi on fixed disks. That’s a bummer. From what I remember, iff there are no boot entries, the firmware is expected to eventually try the removable device binary path even on fixed disks as part of recovery. In any of those scenarios, EFI/boot is an optional vendor directory which should contain boot<arch>.efi binaries to load. That’s what ovmf does, but maybe Fujitsu has some in house EFI firmware implementation.

Can you list the model information of the devices you have observed this behavior on?

#11

@xnox suggested adding EFII/boot/boot.csv which is read by the shim to automatically add a default boot entry. That would work if the firmware boots the shim from a fixed drive eventually?

We also had some questions about the installer, which AFAIU could be in the business of transferring the recovery system to a fixed device and setting up boot entries if needed. Though again, I haven’t looked at the UEFI spec in a long time now, but I understand the setup we use should work in most cases.

#12

I wonder if that works to set up boot loaders on a different ESP though?

If we’ve flashed UC20 onto the fixed disk of the device, and have booted off a thumb drive containing Shim + a boot.csv file, is it going to set up boot variables pointing at the fixed disk or the thumb drive?

#13

Looking at https://github.com/rhboot/shim/blob/5ec906ac6ce4596664a6a7f1626895ebca9cd65e/fallback.c#L518 if I follow the code correctly, boot entries would be added for OS from removable device too? Though in this case a full device path would be used. I suspect that when such device is missing, the boot entry is invalid and would fail to load. It’s unclear what would happen if you reinsert the device.

#14

it always sets up variables from the matching ESP. i.e. shim booted from drive A’s ESP, will setup varaibles for the drive A’s ESP provided .csv.