Boot process freezes in Plymouth after kernel updates

I’m still booting my F35 system into kernel 5.18.11 because the last two kernel updates would get stuck while the Plymouth splash screen was up. I have an Nvidia card in my system; perhaps the issue could be related to that?

I’m hesitant to run the newest kernel update because it would knock the kernel I’m using off the list in grub. It’s time to actually troubleshoot the issue properly now.

Could you try uninstalling the nvidia driver and booting from the newer kernel(s)?
Also post the output of inxi -Fz

You said an nvidia card is installed.
What driver are you using? nvidia or nouveau?
If nvidia, How was it installed? Was it installed from negativo? or nvidia? or rpmfusion?

Can you get the grub menu and then for the kernel that fails to boot press the e key for edit and then tell us the content of the line that begins with ‘linux’ . You can also edit that line and delete the rhgb quiet from that line and continue booting with ctrl-X. Doing so will give you pages of text as it boots and can give us a pointer as to where the hang occurs if it halts during the boot.

Actually that is incorrect. Dnf will never remove the kernel that is currently active, so if you are booted from 5.18.11 it would remove the oldest that is not 5.18.11 as it installs the latest available.

The nvidia driver is used, installed with rpmfusion. The line in grub menu has information about my boot drive’s UUID (luks). It has items that blacklist nouveau, and enables nvidia drm.

Interestingly, the last output before it hangs once the quiet option is removed, is the system attempting to connect or enable my USB trackball. But attempting to boot the system with that device disconnected didn’t stop the system from hanging.

My system uses a Haswell processor. The motherboard uses the B85 chipset and the Nvidia card is a 1050 2gb, non-TI.

I’m sorry but I cannot assist.

You failed to provide the requested info but generalized all the response so I have no detailed info on which to base any suggestions I might make.

If you were willing to provide the detailed info requested then it is possible I and many others may be able to aid in identifying the cause and the fix.

A good start is to provide the output of inxi -Fz

Here’s basically what that linux line reads like when I hit e in the grub menu (obviously taken from /etc/default/grub):

I think grub adds another option about the luks device that doesn’t appear here.
GRUB_CMDLINE_LINUX="rd.luks.uuid=[uuid here] rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init"

This is all default when you install nvidia drivers via rpmfusion.

I still don’t understand exactly why this corrects things, but I’ve managed to boot into the system with the newest kernel.

Once I booted into tty instead of graphical and was unable to start x11 from there, I was able to find more threads about this issue between nvidia and kernels starting with 5.18.13 (by including “breaks xorg” in my query).

In my case (and others), adding nomodeset to the linux line in grub and removing nvidia-drm.modeset=1 allowed me to boot into the system. The latter edit may not have been necessary, but seemed logical after adding nomodeset.

Are these changes safe to make permanent in /etc/default/grub/? The defaults from installing nvidia drivers in rpmfusion have always worked for me in the past.

Since it is working with these changes, make it permanent. I don’t see why it could be unsafe.

1 Like