cfs: Use bootupd for all installs if available#2327
Conversation
3e40503 to
f2eef01
Compare
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 Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
f2eef01 to
edefd33
Compare
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 |
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 |
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.
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 |
|
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
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) |
2 participants
Check if we have a new enough version of bootupd (by checking if the binary provides a
--bootloaderflag). If we have a new enough bootupd, use it to install grub-cc and systemd-bootWe 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