On Tue, Jan 12, 2021 at 8:48 PM Michel Alexandre Salim <michel@xxxxxxxxxxxxxxx> wrote: > > Hi, > > > On Tue, 2021-01-12 at 19:56 +0100, Hans de Goede wrote: > > So I've read Neal's comment there and what he describes really > > is a special corner case, but yes it is possible for people to have > > created the special setup he describes and yes in that case moving > > grubenv to /boot will break the hidden-menu functionality. > > > > I'm not sure if this warrants a -1 to the proposal though, > > I believe documenting this + some workaround for it should be > > sufficient. > > > > But as mentioned in the fesco issue this has more to do with the > > fact that storing the grubenv in a filesystem-file is a bad idea > > in general. > It's not necessarily bad unless the filesystem is journaled, right, > since GRUB's filesystem drivers basically don't support this? (so > basically it's only FAT-like filesystems and ext2 that's perfectly > safe). There are separate issues. grubenv is "OK" on ext4 and XFS. The issue is that none of the file systems developers like anything other than kernel code doing writes. One idea for this is a new MBR and GPT partition type, functionally identical to the GPT "BIOS Boot" type, that's exclusively for the bootloader to use however it wants. On BIOS it'd include core.img and grubenv. On UEFI it'd just be used for grubenv. This issue needs to be taken upstream to sort out the details, so it should be set aside as it relates to this proposal. The issue with journaled file systems is that GRUB's file system drivers have no ability to do journal replay. Therefore there is a small risk the file system is rendered unbootable in a crash, because the bootloader only sees the no-replay state of the file system used for /boot. e.g. the bootloader can see grub.cfg, bls snippets, or even the kernel as either missing or as 0 length files, until the journal has been replayed. Small risk, big penalty. My suggestion for mitigation is to use FAT for /boot in simple cases, and Btrfs in less simple cases. It's just an idea, it's not urgent, but if things are being reconsidered for simplification anyway, this makes sense to me. Ergo the idea for a "bootloader partition that is exclusively owned by the bootloader" is separate from "bootloaders don't do journal replay and therefore can have the wrong view of things, and fail to boot in rare cases following a crash." > 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. I tentatively agree. We should ensure coordination with coreos/bootupd folks and boot loader spec folks that we're all on the same page. -- 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
