On Mon, Nov 2, 2020 at 8:32 AM Jorge Fábregas <jorge.fabregas@xxxxxxxxx> wrote: > I'd like to have my system drive with BTRFS on a RAID1 profile. I was > experminenting with a simple / (root filesystem) subvolume but it > appears GRUB2 can't work properly with it. I get the famous: > > "Sparse file is not allowed" during boot (and no way to access GRUB2 > menu). It boots fine but I can't longer edit the GRUB2 menu during boot. I'm not exactly sure what condition results in this error, but I suspect it's a bug. The message we should see when grubenv is on Btrfs is that grubenv writes on btrfs are disallowed. This is because GRUB (in the pre-boot environment) writes to grubenv not via file system writes but by directly overwriting the two 512 byte blocks that make up grubenv. On btrfs, this is indistinguishable from corruption because the checksum isn't also updated. Further, this 1KiB grubenv file is so small it tends to be an inline extent, i.e. it's sorted inside the 16KiB leaf alone with its inode. If the file were overwritten, it'd invalidate the entire 16KiB leaf. It's possibly a very serious corruption. But GRUB has known this since forever and doesn't do writes to files on Btrfs (or LUKS, or mdraid volumes, and maybe not to LVM). So I suspect this message is just an artifact of having put your /boot on Btrfs on a BIOS system. On BIOS systems, the grubenv is located in /boot/grub2/grubenv which means if you put /boot on Btrfs, it's on Btrfs and can't use GRUB_DEFAULT=saved or the variable GRUB hidden menu feature where it checks for successful boots. Basically, GRUB can't reset the count, so it sees boots as always successful. You can reveal the GRUB menu by F8 (often this includes using Fn key). Or you can do it permanently by `grub2-editenv - unset menu_auto_hide` Meanwhile on UEFI systems, grubenv is always on the FAT formatted EFI System partition. > Fine, I read somewhere that /boot wasn't allowed with BTRFS in Fedora? It's allowed but not the default. > I'd like my desktop to have a RAID1 setup for my main drive and be able > to remove either disk and boot seamlessly. Is this possible with BTFS & > GRUB2 these days? Short version: If you want unattended degraded RAID boot, use mdadm and put Btrfs on top of it. Long version: GRUB is not a factor at all in this. It has had Btrfs support for 11 years, and knows about all the profiles. It supports all the raid types including the new raid1c3 and raid1c4, and knows how to find things even when degraded, and can even reconstruct from parity if /boot were on a raid5 or raid6 with missing disks. The issue is that there's no such thing as automatic degraded mounts in Btrfs. If a device has failed or is missing, you will get a long delay followed by being dropped to a dracut prompt. (At least it used to, I vaguely recall one or two issues where systemd waits for sysroot indefinitely, which seems like it should be a bug.) Why? Missing features to make automatic degraded mounts safe. i.e. if the missing device reappears, it needs to be "caught up" with all the changes since it went missing. Right now you have to do a scrub of the entire volume, and there's no partial scrubs. Where with mdadm raid, there is a write intent bitmap that tells mdadm how to kick off a partial resync. There is some bad advice on the internet (imagine that), suggesting removing the btrfs udev rule that waits for all Btrfs devices to show up before attempting to mount, and also add 'degraded' mount option to fstab. The problem is, any small delay by any device during boot means an immediate degraded mount. And without a scrub to catch up the late device, the mirrors can end up in kind of "split brain" situation, and that's not recoverable or repairable. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx
