Update will fail if update metadata is missing for the current boot type

[HuijingHei]

Fixes #1035

[gemini-code-assist]

Code Review

This pull request correctly implements the desired behavior of failing an update when the metadata for the current boot type is missing. The changes in src/bios.rs and src/efi.rs are clear and effective. The test case in tests/kola/test-bootupd has also been updated to reflect this new behavior for BIOS-booted systems. I've added one suggestion to make the test more robust by making it boot-aware, so it can validate the behavior on both EFI and BIOS systems.

[cgwalters]

why not !is_efi_booted instead of testing the /sys path?

[HuijingHei]

I am concern that it might be not suitable for ppc, as is_efi_booted() is for x86_64, or maybe it is better to move is_efi_booted() out of efi.rs. WDYT?

[alexlarsson]

This change is breaking the builds for automotive.

I'm getting this when using image-builder converting the bootc image to a disk image:

org.osbuild.bootc.install-to-filesystem: a5b26368688ef424171b4a5692348bcd81f254a8a3646ac0abcad254816b27a0 {
  "kernel-args": [
    "rw",
    "console=tty0",
    "console=ttyS0"
  ],
  "target-imgref": "localhost/aib-c21c2b43c83771df5115a465"
}
device/disk (org.osbuild.loopback): loop0 acquired (locked: False)
mount/- (org.osbuild.ext4): mounting /dev/loop0p6 -> /var/tmp/aib-kxl5o3kf/cache/tmp/buildroot-tmp-g4nf_o14/mounts/
mount/boot-efi (org.osbuild.fat): mounting /dev/loop0p1 -> /var/tmp/aib-kxl5o3kf/cache/tmp/buildroot-tmp-g4nf_o14/mounts/boot/efi
Installing image: docker://localhost/aib-c21c2b43c83771df5115a465
Initializing ostree layout
layers already present: 0; layers needed: 65 (372.0Â MB)
Deploying container image...done (7 seconds)
Bootloader: grub
Installing bootloader via bootupd
error: boot data installation failed: Failed to find BIOS update metadata

I don't see this on my machine which has a /sys/firmware/efi directory, but I am seeing it in the internal CI builds, which are probably running on a non-efi system.

[alexlarsson]

Overall, its probably not good that bootupd makes decisions based on host hardware details, as such things will never be right when running in the context of generating images.

[travier]

This was not meant to be triggered at install time but only at update time, so this is a bug.

[alexlarsson]

Then it should be in run_update(), not query_update(), i think. query_update() is called from install().

[travier]

The main concern that led to this PR was that we would remove the EFI binaries if the metadata was not there in the image and that would break an installed system on update: #1018.

But this only matters for the EFI case as we do not "remove" the BIOS boot partition content on BIOS booted systems on update if there is no BIOS component. We just do not update it.

So I would remove the checks for BIOS and only keep the runtime check that if the system is booted via EFI, we should install an EFI component. This would break systems where we would only install BIOS but that does not exists?

[alexlarsson]

@travier I don't think that is enough anyway. Consider building an image targeting android boot (no bios, no efi), this would have an empty efi component, and we would fail to build such an image on an efi booted build machine. I think we need the full #1096 fix