On Tue, Jan 12, 2021 at 10:06 PM Javier Martinez Canillas <javier@xxxxxxxxxxxx> wrote: > > The thing is that implementing this proposal should be straightforward > and something that could be done for F34 but solving the grubenv issue > will require more time, since we first will need to agree with GRUB > upstream on the approach. Agree. > > Also, switching existing installations to the configuration scheme > mentioned in this proposal should be feasible but changing the > partition layout would be much more risky. That's why I believe that > even if we solve the grubenv issue (i.e: in F35), this should only be > for new installations and storing grubenv as a file has to be > supported for backward compatibility. Agree. Unless I can track down a magical leopluradon to do a 100% safe conversion, I think it's OK to just depend on attrition to solve this. I'm sometimes an outlier, but I'm a strong proponent of GUI tools constraining the options available to users, to only that which we recommend and want to support. i.e. it would be a good time for the installer to stop presenting all bootloader related things in the GUI. If the installer team folks want to support esoteric customizations in kickstart, super, I have no complaint. But the GUI, whether auto, custom, advanced, should just stop inviting users to do hapless things. If users precreate their own partitions outside the installer, with a proper GPT GUID, and the installer recognizes and automatically uses those partitions based on GUID, that'd be cool too. I'm very reluctant to ask that more and more things be supported without a plan for either growing resources to support such things. Maintainability is already a problem in the boot realm, both in Fedora and upstream (at least in GRUB). > > > Chris suggested using a BIOS Boot partition, but another possible > > option is to use XBOOTLDR from > > https://systemd.io/BOOT_LOADER_SPECIFICATION/ - which the BLS actually > > prefers over the ESP if found. > > > > Chris' suggestion (unless I misunderstood) is not to use a partition > with a filesystem but instead a partition where the grubenv could be > stored as raw data. That way GRUB should be able to read and write the > grubenv block without using any of its filesystem code (that's > supposed to be read-only). Correct. But also I consider it an implementation detail, decided by those who will implement and maintain it. This hypothetical partition can be used by syslinux, sd-boot, uboot, and others, with whatever they want to put there, in whatever format or scheme they want to implement. It's just a generic bootloader partition, exclusively owned by the bootloader, for whatever purpose it wants to use it for. Likewise, its size is a detail that users don't need to care about. The upstreams can come up with a recommended size. As this hypothetical partition is modeled after the GPT "BIOS Boot" partition it could be 1MiB. If the core.img is pushing that, and if there's some idea to implement an A/B approach in this partition for atomic updating, then 2MiB is fine, even 20MiB is fine - to me those are all the same size :D Even coming from the SD Card in a Raspberry Pi type use case. -- Chris Murphy _______________________________________________ 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
