Re: GRUB2 Behavior Question

[John Little]

I suspect your problem is the linux command in grub.cfg.  There's a
"rootflags" phrase that with btrfs says which subvolume to use.
/etc/fstab in the snapshot has to have the correct entries, too.

However, the grub update mechanisms don't really cope with booting from
snapshots, and are prone to failure with multiple installs generally.
IMO, it is far less work to maintain a grub.cfg manually in a grub
that is independent of any particular OS install.  I used to do this in
a separate small partition, but with btrfs I use a grub subvolume.
With UEFI, and mounting the top level of the btrfs on /mnt/top,

# btrfs su cr /mnt/top/@grub
# grub-install --boot-directory=/mnt/top/@grub/boot \
               --efi-directory=/boot/efi

I use file system labels, which makes the grub menu entries much more
simple and human readable.  For example, I did a btrfs send/receive
backup to a file system labelled "work", in a subvolume named "tuesday".
After editing the /etc/fstab to have

LABEL=work  /   btrfs   defaults,subvol=tuesday,noatime      0       1

I can boot to it with

search --no-floppy --set=root --label "work"
linux /tuesday/boot/vmlinuz root=LABEL=work ro rootflags=subvol=tuesday
initrd /tuesday/boot/initrd.img

With my approach the biggest problem has been to stop the grub scripts
from trampling on it.  Unmounting the EFI partition before APT updates
helps.  I copy the grubx64.efi to mygrubx64.efi and use efibootmgr to
set up a boot entry to it; the grub scripts will change that if they 
can, so I have to change it back with efibootmgr sometimes.

HTH somebody,

--
Regards, John Little