On 29.01.2022 19:50, Eric 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 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.