On Wed, May 3, 2023 at 10:47 PM Joe Salmeri <jmscdba@gmail.com> wrote:
Hi Andrei,
Can you give me a pointer was to where you are referring in the grub configuration?
user@uefi:~> cat /boot/grub2/x86_64-efi/load.cfg set btrfs_relative_path='y' btrfs-mount-subvol ($root) /boot/grub2/x86_64-efi @/boot/grub2/x86_64-efi user@uefi:~>
Thanks for the pointer, but your answer raises the question......
If the file that does the mount ( /boot/grub2/x86_64-efi/load.cfg ) is located on the subvolume being mounted ( /boot/grub2/x86_64-efi/ ) then how does it read that file when the subvolume isn't mounted yet ? There must be another piece I am missing here ???
These commands are embedded in grub.efi by grub-install.
Also, do you know if SUSE has modified grub to mount the default btrfs subvolume?
Yes and no (yes, I know, and no, it did not). It modified grub to resolve paths on btrfs relative to default subvolume if snapshots are enabled.
If yes, are there any plans to submit that patch upstream so that other distros will pick it up?
Upstream grub used default subvolume in the past. It was changed to always access full btrfs exactly because it was impossible to access anything outside of the default subvolume. ...
I have been doing a bunch of testing with snapper and several other linux distros and they all have the same issue in that since they don't have the default subvolume mounted they have to use the rootflags kernel option to specify it and the linux and initrd commands have to specify the full path from the btrfs root volume down to the subvolume.
This breaks snapper rollback functionality on all other distros I've tried because after making the r/w snapshot snapper sets it as the new default snapshot, which on TW, works great and the next boot works from that new default snapshot, whereas on other distros since they don't mount the default snapshot, the boot is still from the original snapshot because of all the hard coded references to the snapshot # in their grub configuration.
Does that make sense?
Snapshot (rollback) is simply incompatible with how grub is using /boot by default. The way SUSE does it remains compatible with "grub at boot time is located below /boot" and "kernel is installed in /boot" and allows to still use grub-install. This breaks os-prober, but os-prober as implemented is the wrong way to multiboot Linux anyway. It is quite possible to - install grub in separate directory (subvolume) - make grub to query for current default subvolume and load its configuration from there grub.cfg in each default subvolume would use full paths that would point to this subvolume, so each grub.cfg would always remain valid and would also work from within other distributions with os-prober. Default subvolume here would be used just as an indication of "current root". Solaris (which implemented this long ago) is using a separate zfs property to indicate currently active root (or boot environment), but this is implementation detail. This is (almost) exactly what happens if Secure Boot is enabled, except for paths relative to the default subvolume. This would require just implementing a command to query the default subvolume which is certainly upstreamable. For completeness one could also allow setting location of /boot/grub/grub.cfg explicitly which would go into load.cfg making grub-install "just work". The main problem of this is the fact that /boot as a grub location is really imprinted deep in the subconscious. Ironically, in the past grub-install *did* support --grub-directory which was then deprecated in favour of always using /boot.
In summary, what I am trying to understand is how TW is using whatever btrfs snapshot is set to the default during the boot process without hard coding the snapshot into all the grub configuration files.
grub is using default subvolume so changing default subvolume automatically changes grub configuration.