On Tue, Oct 14, 2025, at 4:22 AM, Gerd Hoffmann wrote: > There is no need for a different partitioning layout (except when it > comes to supporting existing installs). Using vfat /boot everywhere > is an option, and it would cut down the number of grub modules needed > alot.
Whether that's now or five years from now, there will be a flag day. I'm not aware of Fedora ever having a "you will not be able to boot after this date unless you have the new partition layout and file system scheme". Chris Murphy wrote: >> There's a lot of implied work to do and not a lot of people ready, >> willing, and able to do that work. > > Indeed. And grub tying to support every filesystem under the sun > is IMHO part of the problem. If you think Fedora contributors are too busy sending in GRUB file system bug patches, you might have a look at the upstream GRUB git log and compare it to the Fedora GRUB patch list applied on top of the *current* upstream GRUB release. >> > in particular quite complex ones that are eyed with quite some >> > animosity from kernel upstream. >> >> I have no idea what this is a reference to or how it could be >> relevant. > > kernel filesystem people do not like grub having its own filesystem > implementations, especially when it comes to broken write access > (bypassing the journal etc). This is specious. Upstream file system developers *contribute bug fixes* to GRUB file system drivers. What some file system upstreams don't like is anything other than kernel code writing into the file system, even if it's only overwriting data blocks in the grubenv file. Upstreams can certainly submit a patch to disallow such writes per file system. As I mentioned, quite a few already do not allow it. Lack of journal replay support for a small read only driver isn't brokenness. If the use case requires the journal to be flushed, then it's expected that use case will use FIFREEZE/FITHAW. A possible legit problem though is using FIFREEZE/FITHAW on the root file system. It isn't an atomic operation, and I've definitely had a system get stuck in fsfreeze unable to thaw it. Obviously (open)SUSE isn't running into this problem with their layout, but I don't know how they flush before a reboot or if they do anything differently for a bootloader update. Note that Btrfs is different in that log tree replay is not necessary to make the file system consistent. It's an fsync performance enhancer. If the "boot new kernel" change is only found in the log tree, the bootloader fs driver won't see it, but can still find the old kernel driver. -- Chris Murphy -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
