consider folding into github.com/containers/bootc

[cgwalters]

This project was designed to be distribution independent; that's in theory. In practice today it is tied to both ostree and rpm (though the rpm part is definitely written in an attempted-to-be pluggable way).

But I think it will make more sense to fold this into https://github.com/containers/bootc - we're not going to have non-ostree support anytime soon, and if we do it should work in the same way as bootc. Also, I think we want bootc bootloader update e.g.

Also, the two projects are similarly named and it will be less confusing to just have bootc, not bootc and bootupd.

[dbnicholson]

FWIW, I'm hoping to start using bootupd in Endless OS and I doubt we're going to move to OCI payloads any time in the near future. Not to say that you can't do this or there's not value in unifying there. We'd probably just fork the existing code and carry on with it in that case.

[cgwalters]

and I doubt we're going to move to OCI payloads any time in the near future.

BTW, I'd love to chat about this with you at some point! Or maybe you can just write up at least briefly here why not or what the blockers/problems you see are?

[jmarrero]

I have no issue with this, the only hangup up I could see is how we do messaging about bootc being about doing one thing and doing that thing well (deployments).

I guess the bootloader is part of the deployment so...

bootc manages your deployments including the bootloader, using the container as the source of truth maybe is enough.

[cgwalters]

@dbnicholson what if we did it in a way where one can build bootupd out of bootc git, while keeping all of the existing binaries/etc?

[dbnicholson]

Unfortunately, my project to use bootupd stalled (even though it appeared to work nicely), and I can't see us getting back it soon. I do think this is a nice little project that has nothing to do with containers or OCI storage, but if it's causing you friction to have it separate it won't affect us right now to subsume it. It would be nice to continue to be able to build bootupd as a standalone utility, but I wouldn't spend a lot of time on it.

[cgwalters]

I put up a draft for this at containers/bootc#874

[Conan-Kudo]

FWIW, I had been considering looking into integrating support for this into mainline Fedora variants (and had discussed this with @travier about doing so sometime in the next year or so), but if it merges inside of bootc, I don't think I'd continue pursuing that line. It also wouldn't be useful for me to consider advocating for usage with Btrfs based systems, where this could be useful with too, as the bootc part is irrelevant for that.

[cgwalters]

If we merged into bootc we could pretty easily still support having it run independently, and would probably still need to do so in the short term for backcompat.

It also wouldn't be useful for me to consider advocating for usage with Btrfs based systems, where this could be useful with too, as the bootc part is irrelevant for that.

Hmm, can you be more precise? Do you mean with btrfs transactional-update style snapshots for the OS? If someone other than just you (especially say openSUSE) would soft-commit to trying to help maintain bootupd I am open to continuing to maintain it separately.

[Conan-Kudo]

If we merged into bootc we could pretty easily still support having it run independently, and would probably still need to do so in the short term for backcompat.

If it is merged into bootc, it's off the table for me. It's simply not useful to plan on that when I know it will eventually become useless beyond OCI-based operating systems.

It also wouldn't be useful for me to consider advocating for usage with Btrfs based systems, where this could be useful with too, as the bootc part is irrelevant for that.

Hmm, can you be more precise? Do you mean with btrfs transactional-update style snapshots for the OS? If someone other than just you (especially say openSUSE) would soft-commit to trying to help maintain bootupd I am open to continuing to maintain it separately.

Yes, I do mean with transactional-update style systems. It's something that has been on the roadmap for the CentOS Hyperscale distribution for some time now. The project was paused while the DNF 5 stuff was being sorted out and to prioritize the RPMCoW work, but it is something we'll be picking back up in the near future. One of my goals is to move as much of the operating system into Btrfs as possible and have a mechanism in which bootloader stuff is synced out of the OS volume when needed, and also handle rolling back the bootloader in tandem with the rest of the system when needed.

(CC: @davide125, @michel-slm, @DaanDeMeyer)

If you want openSUSE to be interested in it, you should reach out to them and talk to them about it. I only speak for myself and the projects I am working on. The SUSE distributions have a trivial mechanism for this that they use to handle during package transactions to copy out relevant boot stuff from the OS volume to parts of the disk relevant for system boot, but there isn't a good mechanism for handling using the correct bootloaders when the system is rolled back. From my point of view, this is where a unified external mechanism can be useful. From the talks and presentations I saw before, this seemed to be the solution for that. If it isn't, then I will go and look to something else instead.

[cgwalters]

If it is merged into bootc, it's off the table for me. It's simply not useful to plan on that when I know it will eventually become useless beyond OCI-based operating systems.

Again we can totally maintain the tool to be workable outside of bootc systems, even if it lives in the bootc git. But:

Yes, I do mean with transactional-update style systems. It's something that has been on the roadmap for the CentOS Hyperscale distribution for some time now. The project was paused while the DNF 5 stuff was being sorted out and to prioritize the RPMCoW work, but it is something we'll be picking back up in the near future. One of my goals is to move as much of the operating system into Btrfs as possible and have a mechanism in which bootloader stuff is synced out of the OS volume when needed, and also handle rolling back the bootloader in tandem with the rest of the system when needed

This makes sense to me except the last part: I don't think one usually wants to roll back the bootloader when rolling back the OS, at least not by default. The case we've seen more is where we need to update shim (+grub) in order to update the kernel.

[Conan-Kudo]

The main case where it makes sense is when an OS update is paired with a configuration change, rolling back the OS in that case also means being able to roll back the bootloader. This is not even a hypothetical consideration. For example: RHEL 8 to RHEL 9 involved an incompatible change to how GRUB's BLS module (and configuration) worked. Thus, a rollback necessitates having the correct GRUB to read those snippets.

[Conan-Kudo]

If it is merged into bootc, it's off the table for me. It's simply not useful to plan on that when I know it will eventually become useless beyond OCI-based operating systems.

Again we can totally maintain the tool to be workable outside of bootc systems, even if it lives in the bootc git. But:

But the two will become integrated and I will have to deal with bootc when it is unwanted and unnecessary. It's a flat discouragement of using bootupd for regular systems and alternatives to OCI-based OSes.

[travier]

But the two will become integrated and I will have to deal with bootc when it is unwanted and unnecessary. It's a flat discouragement of using bootupd for regular systems and alternatives to OCI-based OSes.

I think the goal is to reduce the overhead for releases but there could still be two distinct binaries and a distinct sub-package.

[cgwalters]

I'm fine holding off on this for a few months, and I will try to put in a little bit of prep and other cleanup work to support non-bootc/ostree systems.

[dbnicholson]

FWIW, I actually picked this up for Endless again about a month ago. I still think it's nice to have this as an independent project since it has no dependency on bootc, but if you want to take this another direction, I won't complain. However, stuff like 5784dba seems more likely to happen in bootc. As far as I can tell, there was no reason for that change besides "we did this somewhere else", but now I can't build it on our stable release unless I go update rust first.

[Conan-Kudo]

There's also the idea of using bootupd to fix the fact the way ARM bootloader stuff is managed on Fedora is not very complete. I'd like to have a similar smooth experience like we have with Fedora Asahi Remix with regular Fedora ARM (where all the weird bits and bobs are installed to the right places automatically and upgraded when the system is updated).

We have this on Fedora Asahi Remix with update-m1n1, but it's more complex with regular Fedora ARM because of the broad hardware set and weird setup structures for all of them.

[cgwalters]

FWIW, I actually picked this up for Endless again about a month ago.

OK, cool.

However, stuff like 5784dba seems more likely to happen in bootc. As far as I can tell, there was no reason for that change besides "we did this somewhere else", but now I can't build it on our stable release unless I go update rust first.

I don't think that's true necessarily...more of a general "Rust MSRV inflation" issue seen everywhere.

[cgwalters]

There's also the idea of using bootupd to fix the fact the way ARM bootloader stuff is managed on Fedora is not very complete. I'd like to have a similar smooth experience like we have with Fedora Asahi Remix with regular Fedora ARM (where all the weird bits and bobs are installed to the right places automatically and upgraded when the system is updated).

I've seen https://github.com/ondrejbudai/fedora-bootc-raspi/blob/cbff66a8bdb82b6276814765ffdb82c4ec4efa9c/bootupctl-shim#L8 - what else is in this space?

Oh I see it's https://github.com/AsahiLinux/asahi-scripts/blob/main/update-m1n1 and there's also https://github.com/AsahiLinux/asahi-scripts/blob/main/update-grub

Yeah, bootupd looks a bit better than that stuff.

[Conan-Kudo]

Right, so while I'm not in love with it being in Rust (as it's a language I'm not particularly good at working with), I would like to have these problems solved in mainline Fedora (and eventually export these solutions to other distributions), and I think bootupd is a decent chance at it.