Boot entering emergency mode with kernel 5.18.17-200.fc36

Hello, after updating to kernel 5.18.17 today, I got this screen:

I’m using Fedora 36, Nvidia driver 515.65.01 and my system is fully encrypted.


Apologies for stating the obvious, but you should save the generated txt file which has the details for the crash, check journalctl output for boot errors, boot the previous kernel using your grub menu, then take a look at the txt file for clues and filing a bug report.
You’re at a command line shell at the moment, so the usual commands are at your disposal. If you’re not familiar with the command line interface, then we’ll have to talk you through it.

Thanks for the reply. Journalctl outputs:

Failed to start initrd-switch-root service.


Failed to switch root: Specified switch root path /sysroot does not seem to be an OS tree. os-release file is missing

So I guess it is a problem with systemd?

The previous kernel version 5.18.16 works fine.

1 Like

Same thing after upgrading to kernel 5.18.17 with same rdsosreport.txt message.

I also ran into this issue. I was able to boot into the previous kernel. I tried reinstalling the kernel a few times, once even removing the initramfs and vmlinuz files for this kernel. That didn’t work.

I then ran "grubby --info=ALL. I saw that the new kernel args line was as follows.

args=“rhgb quiet mem_sleep_default=deep resume=UUID=[number] resume_offset=[number]”

This line is missing “ro rootflags=subvol=root” just after the args=. I was able to get the new kernel to load by removing all arguments on that second line, then re-adding the arguments prepended with “ro rootflags=subvol=root” with the appropriate grubby command. This fix resolved the problem so that I was able to boot to the new kernel.

Important note to any reading this post. Please do not just copy the contents of the “args=” line into your own grubby command. That line is configured to enable hibernation and deep sleep on my Framework laptop. I have redacted the offset and UUID. Copying and pasting that line will result in your computer not booting to that kernel. If you want to manually fix this, you will need to add “ro rootflags=subvol=root” to your own vmlinuz configuration, or wait for an update from the devs.


Show the contents of /etc/kernel/cmdline. This file contains the options that will be inserted into the bls config file as found in /boot/loader/entries. For quick fix, edit the newest file in /boot/loader/entries and copy the options line from one of the older entries.


So I managed to boot the latest kernel.
I updated grub2 like here:
I don’t know if it’s important, but I disabled KMS (Kernel Mode Setting) like described here: before I updated grub2 because KMS is not necessary for xorg.
After successful booting with nvidia driver, I re-enabled KMS.


I would be very surprised if this made a difference, honestly. Disabling KMS is more likely to cause problems than avoid them. Even though it degrades graphics, it’s not necessarily “safer”.

I have seen some posts with the ‘black screen’ at boot where disabling KMS was the fix. It may or may not be an issue, but if re-enabling it does not cause a problem then it was likely not necessary to disable it to start with.

1 Like

Thank you! I ran into the same issue and this helped me :slight_smile:
I did not disable KMS and it worked.


I made another kernel update to 5.18.18 and got the same issue again.
I mean - not so bad, because you just to have to update grub, but every time we get another kernel update…?

Something is happening with the update where the kernel update is not completing properly. I have had to do a reinstall of the kernel with dnf reinstall kernel* and fixed the boot failure on my system .

I have seen the same with both fedora 37 in its pre-release version and with rawhide with kernel updates as well.

If this is the grubby bug, the fix is on testing.

1 Like

WHen that happened, were there any errors? Check the file dnf.rpm.log and/or dnf history info ??? replacing ??? with the actual transaction number.

If any errors did occur it might cause dnf to skip the remaining scriptlets.

The logs on my Fedora 37 VM show this

$ dnf history info 15
Transaction ID : 15
Begin time     : Sat 20 Aug 2022 08:55:46 PM CDT
Begin rpmdb    : f79f9046987a0e06843aea18afc06c2625f64d97c442049bd4f8aa8e14a46664
End time       : Wed 31 Dec 1969 06:00:00 PM CST (-1661046946 seconds)
End rpmdb      : 
User           : jeff <jvian>
Return-Code    : Failure: 1
Releasever     : 
Command Line   : upgrade
Comment        : 

further down in the list this is the only anomaly I see

** Upgrade       twolame-libs-0.4.0-1.fc37.x86_64                                  @fedora
 ** Upgraded      twolame-libs-0.3.13-20.fc37.x86_64                                @@System
    Reason Change Box2D-2.4.1-8.fc37.x86_64                                         @fedora

and in dnf.rpm.log it shows this.

2022-08-20T21:00:00-0500 SUBDEBUG Upgraded: gnome-remote-desktop-43~alpha-2.fc37.x86_64
2022-08-20T21:00:01-0500 SUBDEBUG Upgraded: SDL2-2.0.22-4.fc37.x86_64
2022-08-20T21:00:01-0500 INFO '/etc/resolv.conf' -> '../run/systemd/resolve/stub-resolv.conf'

2022-08-20T21:00:08-0500 INFO warning: %posttrans(kernel-core-5.19.2-300.fc37.x86_64) scriptlet failed, signal 1

2022-08-20T21:00:08-0500 ERROR Error in POSTTRANS scriptlet in rpm package kernel-core
2022-08-20T21:00:08-0500 INFO /bin/kernel-install: line 269:  4120 Hangup                  "$f" add "$KERNEL_VERSION
" "$ENTRY_DIR_ABS" "$@"

2022-08-20T21:10:57-0500 INFO --- logging initialized ---

booting to the new kernel failed, but a removal of that kernel and reinstall fixed the problem.

Almost the same exact error showed and fix worked on the rawhide system

2022-08-20T20:59:01-0500 SUBDEBUG Upgraded: glibc-2.36-1.fc37.x86_64
2022-08-20T20:59:01-0500 INFO '/etc/resolv.conf' -> '../run/systemd/resolve/stub-resolv.conf'

2022-08-20T20:59:10-0500 INFO warning: %posttrans(kernel-core-6.0.0-0.rc1.20220819git4c2d0b039c5c.16.fc38.x86_64) scriptlet failed
, signal 1

2022-08-20T20:59:10-0500 ERROR Error in POSTTRANS scriptlet in rpm package kernel-core
2022-08-20T20:59:11-0500 INFO /bin/kernel-install: line 269:  6397 Hangup                  "$f" add "$KERNEL_VERSION" "$ENTRY_DIR_
ABS" "$@"

2022-08-20T22:15:41-0500 INFO --- logging initialized ---


Something is sending SIGHUP to the scriptlet thus killing it before it is done. Susually that would happen when a terminal session is shutdown. In the old days it would be a modem connected through the telephone which hungup – thus the name. Some time-out, perhaps. Or a DNF bug.

1 Like

@Rainer Peters and @Tim Doran
Thanks, you helped me solving the “Failed to start initrd-switch-root service” boot error"
I got this error while booting with the ‘vmlinuz-5.18.18-200.fc36.x86_64 kernel’.
After rebooting with the previous kernel (5.18.17) I could run ‘grubby --info=ALL’.
This revealed two missing elements in the 5.18.18 kernel definition compared to the 5.18.17:

  • ‘ro rootflags=subvol=root’ was missing in the line ‘args=“rhgb quiet”’.
  • the line ‘root=“UUID=93c1ffa9-ca25-45ce-8d0f-52a028d1c49b”’ was completely missing.

I have used the text elements of the 5.18.17 kernel to restore the 5.18.18 definition
with this (single-line!) grubby-update-kernel command:

sudo grubby --args=“root=UUID=93c1ffa9-ca25-45ce-8d0f-52a028d1c49b ro rootflags=subvol=root” --update-kernel=“/boot/vmlinuz-5.18.18-200.fc36.x86_64”

Before rebooting I also ran ‘sudo dracut --force --regenerate-all’ to update the initramfs-xxx.img files.

The simpler fix is to remove the newer kernel dnf remove kernel*5.18.18* then reinstall it dnf upgrade kernel*. It should properly update with nothing else being done at the same time.

1 Like

There are at least two, maybe three unrelated issues in this thread.

The “option” line in the generated bls files are incomplete

The installation procedure was killed before done

Perhaps to KMS or not to KMS in conection with nvidia drivers.

For malformed “option” line: reinstalling the kernel wouldn’t fix it. It probably comes from bad contents of the file /etc/kernel/cmdline. Unfortunately nobody showed the contents of that file. Recently changes in grub2 has been made to create the contents of /etc/kernel/cmdline with various success.

A good solution to this problem is mentioned here: