Surround it with preformatted tags - three backticks on a line above, three below, or just use the </> button above…
like so
For this kind of output though, where it’s a PITA to type it, just post a picture from your phone - not ideal but better than you making a typo or having to type guids!
Bonus points if it’s in focus and your screen is not covered in fingermarks and dust.
I just tried: mount /dev/nvme0n1p3 /mnt -o subvol=root
The result was:
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/nvme0n1p3, missing codepage or helper program, or other error.
Looking at dmesg, the relevant line seems to be: "BTRFS error (device nvme0n1p3): ‘root’ is not a valid subvolume.”
Hi — hope you’re feeling better.
Since your fstab uses subvolid=5, your root filesystem appears to be mounted from the top-level Btrfs subvolume, not from a named subvolume.
You should be able to mount it directly from the live session:
sudo mount /dev/nvme0n1p3 /mnt
After mounting, run:
ls /mnt
If you see typical system directories such as etc, usr, var, and boot, then you are looking at your installed system.
Yes, I see that from the ls /mnt command.
Great — seeing etc, usr, and var confirms that you have successfully mounted your installed root filesystem.
The boot directory you see there is the mount point for your separate /boot partition, which is why it currently looks empty or incomplete.
Next, you need to mount your /boot and EFI partitions on top of this structure so that the full installed system becomes accessible from the live environment and we can proceed with the repair.
OK, so I will be mounting /dev/vme0n1p1 and /dev/nvme0n1p2. What mount points should I use in the commands?
Yes, exactly.
Since your root is mounted at /mnt, you now mount the other partitions onto their corresponding directories inside that structure:
)
sudo mount /dev/nvme0n1p2 /mnt/boot
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
This mirrors how your installed system normally looks when booted.
After that, we can proceed with preparing the environment for the GRUB repair.
Success. lsblk shows all three mounted to the specified mount points.
Great, that means the system layout is now in place.
Next, bind the virtual filesystems and chroot into your installed system so that GRUB can be regenerated from within it:
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
chroot /mnt
grub2-mkconfig -o /boot/grub2/grub.cfg
This rebuilds the GRUB configuration based on the currently detected system.
That seems to have worked. Reboot now?
Yes — but exit the chroot first, then reboot cleanly:
exit
reboot
I’m still getting the grub error: “…/../grub-core/script/lexer.c:352:…”, with two of the errors being syntax errors and one being incorrect command.
Can you get everything mounted again and check cat /mnt/etc/kernel/cmdline and see if there is anything out of the ordinary there.
If you’re chroot’d
cat /etc/kernel/cmdline
Okay, so we’ve ruled out one possibility.
The grub.cfg file was created, but it contains invalid code that GRUB cannot interpret during boot.
This can also happen if fragments of old configurations or incorrect scripts are located in /etc/grub.d/ that grub2-mkconfig copied to the final file.
mount /dev/nvme0n1p3 /mnt
mount /dev/nvme0n1p2 /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
chroot /mnt
Then
rm /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/grub2/grub.cfg
And
cat /etc/default/grub
(before you delete grub.cfg)
It should look like this:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
Here are two screenshots. I ran cat /etc/default/grub both before and after removing the grub file. It seems the grub file did not exist until I ran the grub2-mkconfig command.
At the end of that, I confirmed that there is a /boot/grub2/grub.cfg file. It is 249 lines long.
There seems a definite error in the GRUB-CMDLINE-LINUX entry. There are 2 resume= entries with different UUIDs. A system can only resume from hibernation using one UUID and it must be the UUID of the physical swap space used for storing the RAM content at time of hibernation.
I believe the < and > characters in the second resume= entry in that file are what grub was complaining about. The structure of the first resume= entry appears correct, but of course only you can tell us which UUID is correct
Are you actually using hibernation? If not then both those entries should be removed. If so then remove the invalid entry there. You will need to repeat the command grub2-mkconfig -o /boot/grub2/grub.cfg after editing the /etc/default/grub file.
I am not sure the below is totally correct
If you are booting using uefi (and it appears you are) then you should also run
sudo --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars as that is also a separate file system and is required to fully activate the chroot environment.
Finally, when running as the user root it is not correct to use sudo for commands since the root user already has full permissions on the system.
To confirm if you are actually running as the root user you can use echo $USER or echo $UID. If the first returns root or the second returns 0 then you are acting as root and should never use sudo.
After recreating the /boot/grub2/grub.cfg file were you able to boot normally?
I had successfully set up hibernation in “Fedora Linux (6.15. ….)”. Hibernation failed after updating to version 6.16, and I haven’t gotten around to trying to fix it. The computer was running OK until updating to 6.18.8, where I started having grub troubles. (Hibernation is important to me.)
