On Sat, Jan 29, 2022 at 12:47 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Sorry about the vagueness. I was afraid my post was too long already, and wanted to see what info was requested before spamming everything I could think of. I also felt there was some simple thing I was missing and hoped someone could provide some clue based on what I wrote. And in fact there was such a thing, and your response had a clue toward it.
I was missing one key difference between my btrfs subvolume layout and
On 29.01.2022 19:50, Eric wrote: the
standard one that SUSE_BTRFS_SNAPSHOT_BOOTING was expecting. I have my / mounted from a subvolume @ whereas the standard one mounts the btrfs root to /.
No, it does not. Standard one mounts default subvolume, not root of btrfs. You seem to misunderstand how booting from snapshot is implemented in SLE.
I'm clearly missing a few things and need to do more homework before I try again. Like I had missed that there was a "default subvolume." It sounds like setting my default subvolume to my @ subvolume would enable grub with SUSE_BTRFS_SNAPSHOT_BOOTING to read it properly.
Realizing this made the error message finally make sense to me.
I was able to get grub working again by running the grub2-mkconfig and grub2-install with SUSE_BTRFS_SNAPSHOT_BOOTING disabled from a chroot from a LIVE usb boot. I'd thought I'd tried that, but must have not had all the right pieces in place in the several variations of that I tried.
So after all these troubles you ended up with the same configuration as before but with more complicated subvolume layout than necessary.
Having subvolumes for /var and such would seem to be a better layout regardless, giving me leaner snapshots, without data I wouldn't want to roll back. I don't have time to play with it further right now, but I haven't ruled out trying again.