On Mon, Oct 13, 2025, at 10:17 AM, Lennart Poettering wrote:

> It doesn't help you if /boot/ is something better than VFAT, for the
> simple reason that the ESP effectively *must* be VFAT, 

It does help putting /boot on a Btrfs pool. We don't have to worry about the 
size of /boot - which is what this whole thread is about. A 1 GiB boot is not 
big enough anymore. And one day 2 GiB won't be enough.

For practical purposes, fixing this requires reprovisioning. We can't automate 
fixing this problem on a live system with current tools. But we could prevent 
it from being an issue entirely.


>and you need to
> update the ESP pretty much as often as the /boot/ partition (if it
> even is distinct at all), hence, you gain nothing by using another fs
> here, but you lose a lot, because you have to trust two file system
> drivers now, 

We're trusting a lot more than two fs drivers...

%global grub_modules  " all_video boot blscfg btrfs             \\\
                        cat configfile cryptodisk               \\\
                        echo ext2 f2fs fat font                 \\\
                        gcry_rijndael gcry_rsa gcry_serpent     \\\
                        gcry_sha256 gcry_twofish gcry_whirlpool \\\
                        gfxmenu gfxterm gzio                    \\\
                        halt hfsplus http increment iso9660     \\\
                        jpeg loadenv loopback linux lvm luks    \\\
                        luks2                                   \\\
                        memdisk                                 \\\
                        mdraid09 mdraid1x minicmd net           \\\
                        normal part_apple part_msdos part_gpt   \\\
                        password_pbkdf2 pgp png reboot regexp   \\\
                        search search_fs_uuid search_fs_file    \\\
                        search_label serial sleep               \\\
                        squash4                                 \\\
                        syslinuxcfg                             \\\
                        test tftp version video xfs zstd "

These are all in the signed grubx64.efi binary.

GRUB is enabling Fedora to support a wide assortment of architectures, some of 
which do not use UEFI. Therefore sd-boot isn't a drop in replacement, and 
therefore it would be an additional boot loader, and partitioning layout.

There's quite a list of modifications needed to support it still. We don't have 
the correct directory and file layout on XBOOTLDR. That would need to be fixed 
in the kernel RPMs and also the GRUB blscfg patches so the new and old 
locations can be discovered. Installer enhancements are likewise needed.

There's a lot of implied work to do and not a lot of people ready, willing, and 
able to do that work.


>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.

-- 
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

Reply via email to