cfs: Use bootupd for all installs if available

[Johan-Liebert1]

Check if we have a new enough version of bootupd (by checking if the binary provides a --bootloader flag). If we have a new enough bootupd, use it to install grub-cc and systemd-boot

We do not have this version of bootupd as an rpm package, so this will not break any existing systems.

This is mostly for reverse dep testing in bootupd as testing this for bootc requires packaging bootupd, updating grub-cc and systemd-boot rpms to install their respective EFI binaries in the correct place which they don't right now

[cgwalters]

Check if we have a new enough version of bootupd (by checking if the binary provides a --bootloader flag). If we have a new enough bootupd, use it to install grub-cc and systemd-boot

This isn't semantically equivalent though, bootupd always installs shim too, but the current direct bootc support for systemd-boot (intentionally) doesn't.

This is kind of a gap in the flow today, as I think our Fedora-derivative examples still include the shim RPM. OK I just did redhat-cop/rhel-bootc-examples#18

[Johan-Liebert1]

This isn't semantically equivalent though, bootupd always installs shim too, but the current direct bootc support for systemd-boot (intentionally) doesn't.

yes, that's why this shouldn't affect the current flow, at least until we decide to make a new bootupd release. On that topic, we did have a discussion about a --no-shim flag in bootupd. We could go ahead and add that to bootupd to make it compatible with our current flow

[cgwalters]

yes, that's why this shouldn't affect the current flow, at least until we decide to make a new bootupd release. On that topic, we did have a discussion about a --no-shim flag in bootupd.

Well, I think people who don't want shim shouldn't include it in their images to start in general. I'm uncertain about dynamic choice for a generic image.

We could go ahead and add that to bootupd to make it compatible with our current flow

Our current sealed+systemd-boot flow is removing bootupd. For people who do have bootupd and systemd-boot installed and don't have shim, then yes, we could have bootupd just do a systemd-boot install.

Actually though, this gets to a very messy topic of our bootloader detection/CLI vs bootupd. We still unfortunately do need to detect grub vs systemd-boot dynamically, but ideally in the future after grub/grub-cc design fixes we don't need to do that anymore - we honor anything that implements the BLS in general.

For installing the bootloader and determining what was installed, otherwise it's just bootupd's job. The API surface for that might as you argue be --bootloader= too, although I think perhaps in the future it should actually be --bootupd-bootloader= to clearly differentate "managed by bootupd" vs not.

[Johan-Liebert1]

So, for now do we also check for shim's existence along with sd-boot, and if shim doesn't exist proceed with bootctl else defer to bootupd? Or, would you say adding "no-shim" support in bootupd is better? We probably don't need a no-shim flag in bootupd as we can just simply skip it if it doesn't exist

--bootupd-bootloader= to clearly differentate "managed by bootupd" vs not.

this is an interesting case as, afaik, our bootupd sd-boot installation approach would be incompatible with bootctl (I'll have to test it out)