On Tue, Feb 9, 2021 at 12:26 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Feb 9, 2021 at 11:40 AM Martin Kolman <mkolman@xxxxxxxxxx> wrote: > > > > On Tue, 2021-02-09 at 09:50 -0700, Chris Murphy wrote: > > > On Tue, Feb 9, 2021 at 9:15 AM Michel Alexandre Salim > > > <michel@xxxxxxxxxxxxxxx> wrote: > > > > There's a further complication: Chris just informed me that on BIOS > > > > systems, space is more of a constraint so the zstd module is not part > > > > of GRUB ... meaning we have to handle these two scenarios: > > > > > > It's available, but it's the 2nd largest GRUB module at ~100KiB. And > > > on BIOS we're space limit right now to 1 MiB MBR gap or BIOS Boot > > > partition. > > > > > > GRUB works fine with a zstd compressed /boot/ but obviously there's > > > next to no benefit compared to the added complexity since the kernel > > > and initramfs are already compressed. > > > > > > So if it's not difficult to exclude compression on /boot/ that's > > > probably preferred? > > > Are we talking about custom partitioning layouts ? > > For Fedora 34, yes. There's an idea/pre-plan for Fedora 35/36 to put > /boot/ on Btrfs by default; but it's contingent on GRUB changes needed > upstream to better support grubenv by putting it on a dedicated > partition. [1] :D [1] GRUB disallows writes to it from the pre-boot environment when grubenv is on mdadm, luks, btrfs, zfs; while GRUB allows writes to grubenv when on ext[234] and XFS the fs developers really frown on anything other than kernel code writing to a file system owned partition, even if that write is just a data block overwrite. So the idea is to stop doing it and give grubenv it's own partition sorta like BIOS Boot. -- Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
