Description of problem: With /boot on btrfs the following error message briefly appears on boot: loadenv.c:216:sparse file not allowed This appears to be because grub is failing to write the last booted kernel information to disk. This error message didn't appear with Fedora 33 and so is a regression. Version-Release number of selected component (if applicable): # rpm -q -a | grep grub grub2-common-2.06~rc1-4.fc34.noarch grub2-pc-modules-2.06~rc1-4.fc34.noarch grubby-8.40-51.fc34.x86_64 grub2-tools-minimal-2.06~rc1-4.fc34.x86_64 grub2-tools-2.06~rc1-4.fc34.x86_64 grub2-efi-ia32-2.06~rc1-4.fc34.x86_64 grub2-efi-x64-2.06~rc1-4.fc34.x86_64 grub2-pc-2.06~rc1-4.fc34.x86_64 grub2-tools-efi-2.06~rc1-4.fc34.x86_64 grub2-tools-extra-2.06~rc1-4.fc34.x86_64 grub2-efi-ia32-cdboot-2.06~rc1-4.fc34.x86_64 grub2-efi-x64-cdboot-2.06~rc1-4.fc34.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install/updgrade to Fedora 34 with /boot as a btrfs filesystem 2. Boot 3. See this error briefly on booting: loadenv.c:216:sparse file not allowed Actual results: See this error briefly on booting: loadenv.c:216:sparse file not allowed Expected results: No error Additional info: https://bugs.mageia.org/show_bug.cgi?id=18781 https://bugzilla.opensuse.org/show_bug.cgi?id=849718 https://bugzilla.opensuse.org/show_bug.cgi?id=856391 https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/736743
https://forums.fedoraforum.org/showthread.php?325913-Grub2-error-message&p=1846439
This isn't a default configuration. It's one of the reasons /boot is still on ext4 by default. GRUB preboot writes to grubenv by just overwriting the two blocks making up the file, without updating any Btrfs metadata because the GRUB btrfs.mod driver is read-only. Just like all of its file system drivers. On ext4 this isn't a problem because, no data checksums or inline extents yet. Btrfs (and ZFS) will see such overwrites as corruption, therefore GRUB disallows writes to grubenv when it's on Btrfs, ZFS, mdadm raid, LUKS, and possibly LVM. Upstream needs to redesign grubenv is what it comes down to. There's several different ways grubenv could be allocated that might explain why you're not seeing the error in Fedora 33 but you are in Fedora 34. But when the error happens, it's legit, it's not a bug. It's a design issue. As a consequence of putting grubenv on Btrfs, GRUB can't zero out boot_success, so it always thinks boots succeeded. Therefore the GRUB menu is always hidden even following a failed boot. The foreseeable future means grubenv on ext4, or you can F8, Esc, or Tab (not sure which one) to reveal the hidden GRUB menu, or you can disable the hidden grub menu feature with sudo grub2-editenv - unset menu_auto_hide
Nb. there a way ("hack") to disable checksum checking for a file: one needs to set NO_COW attribute when the file is initially created empty. When the file already has some data, it's too late.