grub fails to rescue prompt: '/boot/grub2/x86_64-efi' not found.
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 @ and how can I fix this? --------------------- 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 (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.
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.
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 <arvidjaar@gmail.com> 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 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.
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. But whatever works for you.
Anyway, thanks for your response Andrei!
On Sat, Jan 29, 2022 at 7:10 AM Andrei Borzenkov <arvidjaar@gmail.com> 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 <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.
participants (2)
-
Andrei Borzenkov -
Eric