On Wed, 2020-12-30 at 12:21 -0800, Adam Williamson wrote: > On Wed, 2020-12-30 at 14:53 -0500, Ben Cotton wrote: > > == Benefit to Fedora == > > > > This change will not only simplify and make less confusing the GRUB > > configuration but also allow the following improvements: > > > > * To have a consistent configuration across all the architectures > > using GRUB. > > * Allow the same installation to be booted with either EFI or > > legacy BIOS. > > * Use the same documentation and commands for all architectures > > instead of having EFI as a special case. > > * Make GRUB configuration tools more robust by not relying on > > symbolic > > links to be created and not having to handle platform specific > > cases. > > * Align with images generated by COSA and OSBuild on how the GRUB > > configuration files are used. > > * Align with other Linux distributions on how the GRUB > > configuration > > files are used. > There's discussion in emails and IRC this morning that have not made it back to this Change, these are some of them but apologies if I miss some: - right now putting /boot on btrfs (or xfs) works on EFI systems, since the GRUB config is on the EFI partition that Grub can write to. With this change, it's no longer an option unless /boot/grub2 is made a separate partition - for comparison, SUSE stores GRUB environment variables in the Btrfs header, but apart from having to maintain a patch, this would not help the goal of unifying the config, nor help those who want a single / xfs partition - a separate partition for storing GRUB config, no matter what architecture, is probably the ideal solution > But: > > > == Upgrade/compatibility impact == > > > > The changes will only be for new installations, existing systems > > will > > not be impacted and will continue using the grub.cfg and grubenv > > files > > that are located in the ESP. > > To me several of the benefits seem to not really be true, so long as > this is the plan for upgrades. > > * We wouldn't have a "consistent configuration" across everybody, > really, because anyone who upgraded from pre-F34 would still have the > old config; every bootloader debugging session ever would start by > figuring out which case this was. > > * We can't really use the same "documentation and commands" for the > same reason. We either have to document both possibilities forever, > or > accept that our docs will be incorrect for anyone who upgraded from > pre-F34. > > * We can't really make the tools "more robust" in the way cited > because > they'll still have to handle both cases as long as both cases exist. > If > anything this makes them more fragile: the more divergent paths a > tool > has to support, the more likely it is something will break. Igor was asking about migrating existing setups, and I think Javier plans to document that with the caveat that it might be flaky. But yeah, potentially having to support three configurations (BIOS only, EFI old style, EFI pointing to the new location), for me, means ideally we can agree on a mechanism that works everywhere, so that at least there's not another configuration change down the road. To bring the separate email thread back to this, now that the Change proposal is out -- I was initially going to bring up a related Change Proposal to make /boot on btrfs work consistently -- it is also predicated on grubenv being writable, which is currently true on EFI but not on BIOS systems. Depending on the final version of this proposal, I can retarget mine (that Javier kindly offered to help with, to help with any needed GRUB changes) for F35 to be about actually switching /boot to be on btrfs on Fedora solutions that are Btrfs-based -- on the same partition as / if LUKS is not used, and on a separate partition if it is, until we have native Btrfs encryption. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
