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.
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.
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.
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.
$ 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
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.
@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:
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.
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.
I ran into this problem with 5.18.19 F36 (now fixed with the solutions mentioned below) and I am also using Xorg instead of Wayland. Could Xorg have a hand in this?
Also, the update whacked my nvidia driver. (Couldn’t be found on boot and reverted to nouveax) I fixed that by removing all nvidia packages and reinstalling akmod-nvidia.x86_64 from the rpmfusion-nonfree-nvidia-driver repo. Again, I suspect the update might not be compensating for Xorg.
This is going to be a lot of work every time we get a kernel update.