Fedora 40 emergency mode after grub

Hello, I’m here because, after upgrading my Fedora Workstation 39 to 40, the system goes in emergency mode after selecting Fedora 40 in grub.

I’ll explain my last actions on laptop to be more precise.

Firstly, I was trying to use Timeshift on Fedora 39 (I installed it with Fedora 36, so not my first version upgrade), so I followed the guide in the comment and typed the following commands into the terminal:

sudo mount -o subvolid=5 /dev/nvme0n1p6 /mnt

cd /mnt 
sudo mv root @
sudo mv home @home

After that, I edited the /etc/fstab file, reflecting these changes:

# /etc/fstab
# Created by anaconda on Fri Jan 13 18:31:45 2023
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
UUID=0937149d-4bb4-421c-b6c8-e301b0429985 /                       btrfs   subvol=@,compress=zstd:1 0 0
UUID=87076ab0-0929-4dcf-a3e3-871e5cc040ee /boot                   ext4    defaults        1 2
UUID=9598-51FD          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=0937149d-4bb4-421c-b6c8-e301b0429985 /home                   btrfs   subvol=@home,compress=zstd:1 0 0

Then I runned sudo systemctl daemon-reload to make systemd load the new changes.
After that, I runned sudo mount -a.
After all of this, Timeshift was working perfectly, I made a Rsync backup on an external ssd and a Btrfs snapshot on device.

After backupping my drive, I decided to upgrade my Fedora 39 to 40, so I firstly runned sudo dnf upgrade --refresh and after updating everything, I typed sudo dnf system-upgrade download --releasever=40.
After downloading and installing all updated packages, I runned sudo dnf system-upgrade reboot.

Everything went normally and as expected, even the loading screen (Windows-stylish so to speak).
Grub made the last version visible and selectable, so I selected that and tried to access the system, but there it comes the hideous emergency mode.
In my case, what appear on screen is:

Generating “/run/initramfs/rdsosreport.txt”

Entering emergency mode. Exit the shell to continue.
Type “journalctl” to view system logs.
You might want to save “/run/initramfs/rdsosreport.txt” to a USB stick or /boot
after mounting them and attach it to a bug report.

Press Enter for maintenance (or press Control-D to continue):

Now, I think the problem could be caused by renaming the root (/) and home(/home) volumes as @ and @home, but I’m not sure about this.
Furthermore, I tried to select Fedora 39 from grub and it goes perfectly, indeed I’m using that at the moment.

Booting on Fedora 39 I also runned sudo grub2-mkconfig -o /etc/grub2.cfg, but none of that works.

I don’t know how to save the journalctl -xb nor /run/initramfs/rdsosreport.txt info on an external usb, I tried journalctl -xb > /dev/sda1 and cat /run/initramfs/rdsosreport.txt > /dev/sda1 to save on a usb I had, but now I can’t even see the usb on Fedora 39.

So, here I am, kindly asking for your help: how can I solve this situation?

PS. For completeness I leave you my current hw/sw config and the dnf.conf file.
Hw/Sw config:

Laptop: Lenovo Legion 5 15ACH6H
RAM: 16.0 GiB
CPU: AMD Ryzen™ 7 5800H with Radeon™ Graphics × 16
iGPU: AMD Radeon™ Graphics
dGPU: NVIDIA GeForce RTX™ 3070 Laptop GPU

Firmware: GKCN64WW
OS: Fedora Linux 40 (Workstation Edition)
Windowing: Wayland
Kernel: Linux 6.9.4-100.fc39.x86_64



Fedora by default names those subvolumes ‘root’ and ‘home’, though systemd-boot expects then to be ‘@’ and ‘@home’ AFAIK

The mount lines with the subvol names in /etc/fstab must match the way they are named in the file system.
The initramfs image must also match the way they are named on the btrfs volume.

Did you run dracut --force after changing the names on the drive as well as changing the entries in fstab?

This log would provide information that is necessary to actually identify what went wrong.
Please provide the relevant parts (usually summarized at the end) so we can see exactly where the boot failed.

Also provide the output of lsblk -f which should show the subvolume names that are actually mounted and exist on the btrfs file system.

Oh, thanks for your time, fortunately I already resolved this problem also thanks to a reddit user who had a similar problem a while ago.

I will write the solution also here (and leave a link to the reddit discussion which is, I think, more useful).

If you have the same problem as me (caused by renaming root and home subvolume to make timeshift usable) then follow these steps:

  1. when grub shows the entries (kernel options) press e on your keyboard, so you can edit the the grub command line;

  2. while in editing mode, go on the UUID[…] line and where you find subvol=/ change it to subvol=@;

  3. press Ctlr+X to exit the editing mode and instantly boot in that kernel option;

  4. now, open a terminal and reinstall these packages: sudo dnf reinstall shim grub2-common grub2-efi kernel-core;

  5. after doing that, refresh grub with the following command: sudo grub2-mkconfig -o /boot/grub2/grub.cfg;

  6. at this point, everything should work, so try to reboot you pc and test the functioning

Note: The only drawback I noticed is that, when booting with last kernel (Fedora 40 6.9.5-200.fc40.x86_64) a black screen with a white blinking cursor appears before the gdm (I’m on GNOME 46.2) lock screen

Reddit discussion: link