Fedora 29 (30?) hang on boot (nvidia) kernel 5.0.[89]-200

Project Discussion
1

Anyone else experience this problem?

Fedora 29 and NVidia card has been working flawless for a week or so when I got this laptop and installed Fedora. Today I got a kernel update from 5.0.7 to 5.0.8 and the kernel did not boot. I tried the updates-testing kernel 5.0.9 with the same sad result. The resolution has been to go back to use the 5.0.7 kernel.

bash-4.4$ sudo rpm -qa kernel\* kmod\* akmod\* \*nvidia\* | sort
akmod-nvidia-418.56-1.fc29.x86_64
akmods-0.5.6-19.fc29.noarch
kernel-5.0.7-200.fc29.x86_64
kernel-5.0.9-200.fc29.x86_64
kernel-core-5.0.7-200.fc29.x86_64
kernel-core-5.0.9-200.fc29.x86_64
kernel-devel-5.0.7-200.fc29.x86_64
kernel-devel-5.0.9-200.fc29.x86_64
kernel-headers-5.0.9-200.fc29.x86_64
kernel-modules-5.0.7-200.fc29.x86_64
kernel-modules-5.0.9-200.fc29.x86_64
kernel-modules-extra-5.0.7-200.fc29.x86_64
kernel-modules-extra-5.0.9-200.fc29.x86_64
kernel-tools-5.0.9-200.fc29.x86_64
kernel-tools-libs-5.0.9-200.fc29.x86_64
kmod-25-3.fc29.x86_64
kmod-libs-25-3.fc29.x86_64
kmod-nvidia-5.0.7-200.fc29.x86_64-418.56-1.fc29.x86_64
kmod-nvidia-5.0.9-200.fc29.x86_64-418.56-1.fc29.x86_64
kmodtool-1-33.fc29.noarch
nvidia-query-resource-opengl-1.0.0-4.fc29.x86_64
nvidia-query-resource-opengl-lib-1.0.0-4.fc29.x86_64
nvidia-settings-418.56-1.fc29.x86_64
nvidia-xconfig-418.56-1.fc29.x86_64
xorg-x11-drv-nvidia-418.56-1.fc29.x86_64
xorg-x11-drv-nvidia-cuda-libs-418.56-1.fc29.x86_64
xorg-x11-drv-nvidia-kmodsrc-418.56-1.fc29.x86_64
xorg-x11-drv-nvidia-libs-418.56-1.fc29.x86_64

Interestingly the nvidia kernel modules in the generated kmod-nvidia is of the same size in both the 5.0.7 and 5.0.9 version so I think the rebuild has been with no trouble. But the boot fails.

Any ideas

2

Random question @nsmeds…Are you using the GNOME Wayland or GNOME Classic session/shell?

The reason I ask is that I couldn’t get GNOME Classic to boot past 5.0.7-200.fc29.x86_64, and It wouldn’t boot any fc30 kernel. Yet default GNOME Wayland will boot 5.0.8-300.fc30.x86_64, and 5.0.9-301.fc30.x86_64 faultlessly.

The issue that I had sounds very similar, select kernel from grub, boot plymouth…(I personally use Spinfinity as it’s quite smart), enter user/login password credentials, and then it hangs permanently on black/blank screen with no mouse cursor showing at all in the bottom right corner/portion.

My fix was to select GNOME Wayland over GNOME Classic via the user/login screen environment/session/shell cog.

I then removed GNOME Classic after that palaver. Maybe it’s completely unrelated but worth you looking into.

3

Hi, thanks for your comment. I am not running GNOME Classic. My hang is before being presented a login screen.

I pass through pretty much the whole boot procedure up until:
“Starting Show Plymouth Boot Screen”

The next thing that happens is that I get the authorization screen for LUKS2 to un-lock my /home partition, once that is done I get the boot console back as shown in the attached image.

I am running the LXDE spin of Fedora.
bash-4.4$ sudo dnf list *session* --installed
Installed Packages
lxsession.x86_64 0.5.4-1.fc29 @updates
lxsession-edit.x86_64 0.5.4-1.fc29 @updates
non-session-manager.x86_64 1.2.0-15.git16885e69.fc29 @fedora

Bootscreen-freeze
Bootscreen-freeze1307×1743 189 KB

/Nils

4

Hi @nsmeds,
Welcome to the forum!
Did you look at your boot logs? Try journalctl --system --list-boots to find the offending boot (in particular it’s ID). Then journalctl --system --boot[=ID] to list that boot. You should be able to find something to point you in the right direction for troubleshooting this. The [ and] are not entered, if you didn’t give the = and ID it would just display the current boot log.

5

I had a similar issue. Looks like things have changed in the modules signing mechanism: see 1701096 – Fedora 29 - Kernel does not load signed modules

It turns out the issue for me was a setting in the BIOS, in the Secure Boot. I had “secure boot for Windows UEFI” enabled, when I enabled the non-windows specific Secure Boot mechanism, it started working again fine.

You can also try disabling secure boot in the BIOS, or similar, to pinpoint a solution.

Hope it helps

6

Cortexmic,

Thank you very much. Disabling secure boot (allow any operating system) fixed the problem.

/Nils

7

For some added context here: AFAIK it’s either not possible or not easy to make the proprietary nvidia driver (or any unsigned kernel modules) work with secure boot.