Begin the process of using single tool (likely bootupd) for most boot loader updates, especially grub and shim. This decouples package installation, e.g., via rpm transaction, from actual update in /boot and /boot/efi. This change does not affect zipl and systemd-boot.
The implementation details for this change are not fully fleshed out yet but we believe that there is a general agreement that this is the right way to go, so we are submitting it to start the discussion around how we should implement it. We will update the change based on feedback from those discussions.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.
+1
I want to be clear what my vote below means. The proposal is written from the POV of a system with grub2 and shim. Those packages currently use the dump-stuff-into-boot approach, and the diagnosis in the Change text applies to them. It doesn't apply to more niche things like sd-boot, or direct boot from UKIs directly, etc. "Phase 1" is about updating the layout and mechanisms for grub2 and shim and is very welcome.
Phase 1, option 2 proposes extending kernel-install. As discussed in the fedora-devel thread, I think bootctl would be a better fit, which would be "option 4". The implementation details are quite vague at this point, but I think this is OK: the actual installation process is quite simple, so we don't need to decide which option (or options) to implement right now.
kernel-install
bootctl
"Phase 2" is even more speculative, so I'm explicitly not voting on that yet. I have strong doubts whether we want bootupd to do bootloader installation. The reason is not that it doesn't (or won't) do things correctly, but rather that I don't see the justification for yet-another component to be involved. Bootupd was initially introduced with (IMO) weak justification — essentially to wrap how grub2 and shim are deployed. I expect that we'll be able to add missing bits to existing tools and end up with a much leaner system in the end.
+1 with the caveats above
bootctl needs to be decoupled from sd-boot, which is a tough lift for anyone to want to do.
Please explain what you mean. bootctl is already independent from sd-boot, in the sense that it provides functionality that is not tied to it. And we certainly can add additional functionality to it that provides generic services related to boot loader updates. Speaking for systemd upstream, we wouldn't want to add gnarly functionality related to specific bootloaders and their quirks, but if we can figure out something that is generic and maintainable, there is no problem with adding things.
sd-boot
I'm a bit confused here, there are three options in phase 1 without clear indication what is currently planned to happen, and I think we'd get different results if we voted on these three separately ... option 1 (dumb bash script that runs in %posttrans) seems to be the easiest solution for now, I don't like the others much :D
We were hoping for more feedback/discussion about this, so that we (all) could kinda decide together what the best option would be.
For phase 1, dumb bash script is almost certainly the way we will go, as you say, but it would be nice to also have a plan for the next phase. (:
If that's indeed the plan for Phase 1, then I'm +1.
I'm pretty sure that plan for next phase is out of scope for this change then.
After a week, with no -1 votes and caveats outlined to change owners, this change is APPROVED (+6, 0, 0)
Metadata Update from @amoloney: - Issue tagged with: pending announcement
Announced https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NLMBBH3FKTZBTMUI2AII2JU3TP5YAXKK/
Metadata Update from @fale: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.