Upgrades can clobber alternative EFI bootloader entries

[atheriel]

After starting an upgrade to the 24.04 beta, I ended up with an unbootable system after the second restart (I'm not sure what you call the second stage of the upgrade with the fullscreen progress bar). I don't remember seeing any errors, but I was not paying close attention.

When I was able to inspect the system from a live image USB, I noticed that the boot entries had been clobbered and there was no entry for my bootloader in the ESP at all. I created an entry for the existing bootloader (ZFSBootMenu in my case) manually with efibootmgr and then Pop OS started without issue.

I'm not certain of the cause of this, but I suspect the issue is that we unconditionally delete the current bootloader entry here and then recreate it:

upgrade/data/pop-upgrade.sh

Lines 39 to 46 in 0feac8d

	# Remove the current boot entry
	efibootmgr -b "${current_bootnum}" -B
	# Then add the new entry, with the new name
	efibootmgr -c -L "${new_label}" \
	-d "${efi_disk}" \
	-p "${efi_num}" \
	-l "\EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI"

From my reading, the above code will result in an unbootable system if \EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI does not exist in the ESP -- which is true in my case, because I don't use systemd-boot:

$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* ZFSBootMenu	HD(1,GPT,1b3c913a-d02e-4f8a-8ac4-a83c212e0319,0x800,0x100000)/File(\EFI\ZBM\VMLINUZ.EFI)

I think we could probably avoid this by checking if the entry uses systemd-boot before wiping it. Or if it has the expected Pop OS naming convention. Or both. I think it also might be possible to relabel the boot entry without deleting it an recreating it with the right efibootmgr invocation, which is probably a safer approach in general for operations that could fail.