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 /. 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. Anyway, thanks for your response Andrei! On Sat, Jan 29, 2022 at 7:10 AM Andrei Borzenkov wrote:

On 29.01.2022 08:58, Eric wrote:

...

In short: I added btrfs subvolumes (including @/boot/grub2/x86_64-efi ) to try to get snapshot booting in the grub2 menu to work, and after running an update grub fails to the recovery console and reports

error: ../../grub-core/fs/btrfs.c:1997:file '/boot/grub2/x86_64-efi' not found. error: ../../grub-core/fs/btrfs.c:1997:file '/boot/grub2/x86_64-efi/normal.mod' not found.

From the grub rescue prompt I can

ls @/boot/grub2/x86_64-efi

and it successfully reads that folder. Why can it see this path with the @ and not without the @

Because they are two different paths.

...

and how can I fix this?

Honestly? The most simple and straightforward is to reinstall with snapshots enabled.

...

--------------------- Longer version

My openSUSE system only had a @ subvolume for / and a @home subvolume (which was not a child of the @ subvolume, but a sibling, FWIW). To try to get the grub menu snapshots working, I created subvolumes for /var /usr/local /srv /root and /boot/grub2/x86_64-efi, copying over the contents of the directories they would replace and then moving the subvolumes into the place of the old directories

That is not how openSUSE subvolumes are organized normally when snapshots are enabled. I cannot say whether this can confuse tools or not.

...

(using single user mode for a couple of these such as /var), and added /etc/fstab entries for them. I did a few at a time, rebooting in between to make sure things were working properly. I added SUSE_BTRFS_SNAPSHOT_BOOTING=true into /etc/default/grub and made sure grub2-snapper-plugin was installed. The system booted fine after all of these changes but I hadn't refreshed grub.

At this point I ran a full zypper update, since I was overdue, figuring it would take care of the grub refresh. And I guess it did, but now grub is broken.

I've booted with a usb LIVE image and set up a chroot to run grub2-mkconfig and grub2-install to try to fix it (including once with SUSE_BTRFS_SNAPSHOT_BOOTING disabled again) but I still get the same error.

So start with showing at least some facts about your system, not vague description. Output of following commands would provide some initial information

btrfs subvolume list /mnt btrfs subvolume get-default /mnt cat /mnt/etc/fstab efibootmgr -v cat /boot/efi/EFI/opensuse/grub.cfg grep -v '^#' /mnt/etc/default/grub

Here /mnt - whatever path you mounted you btrfs root on. /boot/efi refers to *your* ESP that is used in your system. You may need to mount it in live environment.

On Sat, Jan 29, 2022 at 12:47 PM Andrei Borzenkov 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.