I tested converting my ext4 root partition to btrfs in a virtual machine (Gnome Boxes with UEFI). What I did:
boot into a live image
use btrfs-convert to convert the root partition from ext4 to btrfs
chroot into the converted partition and reinstall grub³
adjust /etc/fstab
run mkinitcpio -P
The converted system works fine, but before booting there’s a weird error message saying “sparse file not allowed”. This seems to be caused by grub not being able to write to /boot/grub/grubenv on a btrfs partition for features like selecting the last booted system at startup¹.
I found workarounds to this problem, like disabling GRUB_SAVEDEFAULT¹ or placing the entire boot dir into a non-btrfs partition². Yet when letting the Manjaro installer manage the entire drive and specifying to use btrfs, the resulting installation won’t have the aforementioned issue and neither of the workarounds in place.
I’m left wondering what the installer does differently when stating upfront that you want to use a btrfs root partition?
This is what I’m curious about. Why am I not finding any of these workarounds (separate boot partition, disabled save function) when installing Manjaro with the btrfs option?
Because it is disabled anyway? Or was it enabled? Cannot remember exactly, but it was disabled when I installed Manjaro with btrfs last year about February.
Anyway, it doesn’t do any weird stuff when enabled. It gives you only an info message.
Dang, the option GRUB_SAVEDEFAULT is set to true but the line is commented out which I failed to spot at first. Now everything makes sense. Thanks for your help!
There’s really no hope that this option will ever work with btrfs?
Would it be possible to have /boot/grub on a dedicated ext4 partition instead of the entire /boot directory? This way, grub could still remember the last used option (I read it needs write access to /boot/grub/grubenv for that feature to work) and kernels would still be part of a btrfs snapshot.
Sure, but never tested it. I guess grub will not find the boot images then, but could be wrong. Needs testing.
Note that btrfs snapshots will not include boot images (initcpios) and when you do a rollback then /boot will be excluded since it is not btrfs and not the same partition. That would lead to an unbootable system until you recreate the boot images. Keep that in mind.
The idea was to have /boot/grub as dedicated ext4 partition. Why would the entire boot directory be excluded from snapshots and why would boot not be btrfs? (Subpartitioning /boot/grub should leave the /boot directory on the root partition so it should be btrfs.)
I dont´t think so. Because when installing grub this is hardcoded into grub. ( @/boot/grub ) .
You may be able to do so if you insist. But at some point in time it will break.
Well, grub installation is standalone and has no system dependencies. So essentially, it would boot from EFI file, start grub from EFI partition and the grub.cfg has the path to linux images on /@/boot. So in theory, there wouldn’t be a problem. Even on an Upgrade at Patch Version so 6.6.8 → 6.6.9 there will be no problem, since the filename will remain the same.
Problem occour if you install a kernel and then rollback. grub.cfg will still have the menu entry, but the file will not be there. Updating grub.cfg would be needed then, but that’s it.
