Multibooting GRUB from a btrfs subvolume.

[GreyGeek]

....
The one serious change I'd like to see in Ubiquity and in fact, to all installers, is to be able to select a subvolume name at install time when choosing btrfs as the installation format. This one change would save 80-90% of the work of doing multiple installs.

I'm with you there!
I suspect that it would also require a re-write of update-grub that detects when Btrfs is installed and to see the subvolumes as bootable partitions that should be included in the menu. So, if you deleted a subvolume to make room for another install, the update-grub would see the new subvolume and include it in the menu, but not the deleted subvolume.

[oshunluvr]

update-grub works fine for whatever install you're running at the time regardless of subvolume name, it just doesn't parse additional subvolumes which is why I created the custom menu process. It works really well, but it requires manual upkeep.

Actually, it's os-prober that is the hang up. I know some bug reports have been filed and patching has been done with some distros - Fedora mainly - in an attempt to fix this, but I've not really explored the status of it because frankly I'm comfortable how things are working here.

I just had an interesting thought though: What if Ubiquity, along with allowing naming of subvolumes at install time, also put grub in a subvolume? Subsequent installs would detect the existence of the grub sobvolume and offer the choice to add to the existing menu rather than replacing it, thus supporting multi-booting out of the box Of course, once you installed a non-Ubiquity distro, you'd have to repair grub but that's the same as it is now. You'd probably need a grub manager of some sort. This probably wouldn't work unless more distros went to btrfs subvolumes as the default when using btrfs,

[GreyGeek]

That's an even BETTER idea!

[jlittle]

I wanted to clean up my old snapshots, after doing several backups, and an update to grub messing up my set up, so I've revisited this idea. I've found that now the simple, straightforward approach now works. Note that I have subvol=/ mounted as /mnt/top, and the ESP mounted at /boot/efi.

sudo btrfs subvolume create /mnt/top/@grub
sudo grub-install --boot-directory=/mnt/top/@grub/boot --efi-directory=/boot/efi
sudoedit /mnt/top/@grub/boot/grub/grub.cfg

and make my grub.cfg as below. Super simple, and can be redone quickly. When APT installs a new version of grub, it tramples the EFI ubuntu entry, so I just need to notice and rerun the grub-install command.

# John's very minimal grub.cfg
#
set default="0"

insmod part_gpt
insmod btrfs
insmod all_video

menuentry 'Kubuntu Bionic' --class ubuntu --class gnu-linux --class gnu --class os {
set root='hd2,gpt2'
search --no-floppy --set=root --label "main"
linux /@_bionic/vmlinuz root=UUID=c908b7ec-dc1d-4594-85e4-f62a9eb4e44e ro rootflags=subvol=@_bionic
initrd /@_bionic/initrd.img
}
menuentry 'System setup' $menuentry_id_option 'uefi-firmware' {
fwsetup
}

If someone wanted to use this grub.cfg, they'd want to change:

• the labels
• the linux line to have the correct UUID and subvolume names (here @_bionic)
• the search lines to use the correct label, or use --fs-uuid with the correct UUID
• maybe the set root lines; if the search commands are successful the set root is not used, they're there as a fallback

Now, the grub.cfg I use isn't quite so minimal, it uses a picture, a bigger font, and some more entries, but the above is all that's needed.

[GreyGeek]

[emoji41]
Neat!

[jlittle]

Further findings. Firstly, my use of grub-install to set the boot entry won't work with secure boot, because the grubx64.efi executable is signed and can't be changed. I've no need for secure boot, but some reader might.

Secondly, I came up with a way to stop grub-install from trampling on my set-up, when it's run by APT on a new version of the grub package. It is to create another EFI boot entry for a copy of the corrected grub executable:

cd /boot/efi/EFI/ubuntu
sudo cp grubx64.efi mygrubx64.efi
sudo efibootmgr -c -d /dev/sdc -l '\EFI\ubuntu\mygrubx64.efi' -L mine

This will stick if the "debconf" configuration variable grub2/update_nvram is set to false, as revealed by

sudo debconf-show grub-efi-amd64 | grep nvram             
* grub2/update_nvram: false

You're supposed to set this by running sudo dpkg-reconfigure grub-efi-amd64, but be aware that that will rerun grub-install and update-grub. You could live dangerously and edit /var/cache/debconf/config.dat directly.