Auto-boot once into installed OS after succesfull installation

[ahkok]

efibootmgr supports --bootnext. This allows the installer to tell the system to ignore normal boot order and omit booting from an attached USB device, and boot the newly installed system once. On subsequent boots, the USB stick will be booted first again if the normal boot priority order is requiring that.

It may require assistance from CBM to implement this. @dorileo ?

[mdhorn]

We might be able to use the partuuid of the media we just installed to find the boot next target in efibootmgr.

[bryteise]

What is the use case we are working to support here and how does it impact the existing process? I thought CBM set Clear to be booted regardless if it could. So I'm not sure exactly what this would be changing.

[ahkok]

Convenience.

People have USB-first set as boot order by default. They install the OS, don't unplug the USB stick on time, and now they're back in the installer.

The amount of people that want to install a new OS on a bare metal system and NOT boot it right after is incredibly small.

[dorileo]

We could wrap it on cbm or clr-installer could manage it itself. To go with the first option we need to add code to cbm to detect we're in such scenario or add a flag in that case clr-installer would pass such flag when calling cbm. I'm fine either way but I'm leaning towards the flag option.

[ahkok]

A flag seems fine and straightforward (e.g. cbm install --boot-once ? Of course we just have update but you get the idea).

[bryteise]

Hrm I don't really know why cbm would add a flag to essentially call efibootmgr. I'd expect the user would call efibootmgr themselves as needed or the installer would do so itself.

[ahkok]

The installer wouldn't know the right arguments. CBM would?

[bryteise]

The installer is setting up partitions, figuring out arguments should be fairly straightforward.

[dorileo]

@bryteise I agree that if the only use case is post install then yes, the best place to add it all is on the installer side.

[bryteise]

@dorileo Tagged you on a forum post that is perhaps convincing me to go the other way and put something in cbm instead. That would be a higher priority than this enhancement request though due to it potentially improving system health with kernel updates.

[karthikprabhuvinod]

@bryteise @dorileo Just wanted to check if there was something was more discussed here?

[karthikprabhuvinod]

Some notes:

I tried out the efibootmgr and it was simple enough to use it to signal to the firmware what the boot device would be for only the next subsequent boot. However as @mdhorn and I discussed, maybe it is difficult to find match out what the target device we just installed to and whats its hex code for UEFI mgr. In short, I did find not a fool proof way to perform an exact match

sample out from efibootmgr command

kp@dellxps~/clr-installer $  efibootmgr --verbose
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,000A,0005,0006,0007,0001,0002,0003,0004,0009
Boot0000* Linux Boot Loader PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,688f732d-38be-4704-86b1-e6cffac4f22e,0x800,0x47000)/File(\EFI\org.clearlinux\bootloaderx64.efi)
Boot0001* Diskette Drive    BBS(Floppy,Diskette Drive,0x0)..BO
Boot0002* M.2 PCIe SSD  BBS(HD,P0: PM981 NVMe Samsung 512GB,0x0)..BO
Boot0003* USB Storage Device    BBS(USB,USB Storage Device,0x0)..BO
Boot0004* CD/DVD/CD-RW Drive    BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot0005* UEFI: PM981 NVMe Samsung 512GB, Partition 1   HD(1,GPT,688f732d-38be-4704-86b1-e6cffac4f22e,0x800,0x47000)/File(EFI\boot\bootx64.efi)..BO
Boot0006* Linux Firmware Updater    HD(1,GPT,01ce569f-ef1a-452a-acda-8d0ff3b5e350,0x800,0x47000)/File(\EFI\ubuntu\shimx64.efi)\.f.w.u.p.d.x.6.4...e.f.i...
Boot0007* memory card   PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)/HD(1,GPT,01ce569f-ef1a-452a-acda-8d0ff3b5e350,0x800,0x4a800)/File(\EFI\org.clearlinux\bootloaderx64.efi)
Boot0009* Secure Digital (SD) Card  BBS(HD,PCIe cardreader,0x0)..BO
Boot000A* ubuntu    HD(1,GPT,01ce569f-ef1a-452a-acda-8d0ff3b5e350,0x800,0x47000)/File(\EFI\ubuntu\shimx64.efi)

Even If we do that, there is a second hurdle, and here is the scenario

a.) In the BIOS settings, user has not selected MMC as a bootable device b.) User continues with installs from a bootable USB and Install Clear on a MMC card device and reboots c) Since in UEFI it has not been enabled as a boot device, there is no hex code for that device to boot from and hence we cant provide the hex code to the efibootmgr command!

[karthikprabhuvinod]

I think there is a way to create a UEFI var entry even if this device is not set as bootable:

for e.g: to create an UEFI entry for a new mmc device we just installed:

sudo efibootmgr --create --disk /dev/mmcblk0 -p 1 -L "KPTESTMMC" -l 'EFI\boot\bootx64.efi' -u --verbose

[karthikprabhuvinod]

I think there is a way to create a UEFI var entry even if this device is not set as bootable:

for e.g: to create an UEFI entry for a new mmc device we just installed:

sudo efibootmgr --create --disk /dev/mmcblk0 -p 1 -L "KPTESTMMC" -l 'EFI\boot\bootx64.efi' -u --verbose

As i was reading, I realized that creating your UEFI entries has some problems 1.) Some UEFI implementations dont support the entry creations from efibootmgr. It depends on the UEFI implementation of the motherboard maker. So even if works on our test devices, it could certainly fail on someone's else as a lot of Clear users use old hardware too 2.) Even those which do support, there is an overhead of managing UEFI entries as creating a lot of entries can cause filling of NVRAM. efibootmgr only supports deleting and creating of entries , not editing current ones (https://github.com/rhboot/efibootmgr/issues/49)

Also, i considered if we could delete an entry for every new entry created. If that is the case, we need to identify a stale boot entry which means looping through all PARTUUIDS from BLKID output & checking it it exists in current UEFI boot entries .e.g . If it does not, we delete that entry using efibootmgr --delete-bootnum <HEX code>

sample output Shown here: https://github.com/clearlinux/clr-installer/issues/684#issuecomment-637904853

I find this a little sketchy and prone to errors.

[karthikprabhuvinod]

To summarize my past comments, it looks like we can always make the best attempt to set the next boot. But it is never a guarantee because of different UEFI architectures. Also this wouldn't work on Legacy to begin with.

[karthikprabhuvinod]

@ahkok : Hi, just wanted to check with you if you have comments or questions or suggestions.

[karthikprabhuvinod]

So by looking at code, checking with folks , came to the conclusion that CBM only creates boot vars when we run CBM in non-image mode when the right boot partition is mounted at /

i.e: something like /usr/bin/clr-boot-manager update works fine and creates a UEFI boot variables. Anything like /usr/bin/clr-boot-manager update --path=.... OR /usr/bin/clr-boot-manager update --image will make CBM run in image mode and hence not create UEFI boot vars.

However, we there is only one way clr-installer calls CBM i.e: /usr/bin/clr-boot-manager update --path=.... . By earlier observation, no new UEFI entry be created every-time we perform an install. But thats not the case.

Looks like there is some other place where /usr/bin/clr-boot-manager update is being run and it creates those boot entries. This must be happening right after installation and before reboot. I am not sure where! One place was heuristics whenever swupd runs but that only happens after a swupd update & changes to clr-boot-manager or boot files.

So I will unassign this for now & maybe somebody can take it up once there is more clarity