Machine will not boot with a 5.9 kernel

This is what I get reported for the lspi command

lspci -k | grep -EA3 ‘VGA|3D|Display’
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
Subsystem: Gigabyte Technology Co., Ltd Device 3629
Kernel driver in use: nouveau
Kernel modules: nouveau

1 Like

No progress on being able to boot Fedora 32 kernel 5.9.x with the existing Nvidia card. As noted, I am using the nouveau driver which was the default when Fedora was installed on this machine. Have changed the bios setting with no affect on boot success. As noted, the machine is a dual boot and the other linux distribution is booting (5.9.8, 5.9.9, 5.9.10, 5.9.11 and 5.9.12) without incident and is also using the nouveau driver for the card. Short of swapping out the video card with an Gigabyte one I have laying around not sure what else to try.

5.9.x seems to be problematic for Nvidia.

Let’s see if we can get more info, and if needed file a bug upstream with Nouveau developers.

  • How far does the system get in the boot, can you perhaps upload a picture?
  • Can you look at the journal logs from the failed boots if they are listed and get the logs from there?

Nouveau upstream is here, by the way. Nothing much came up with I searched for “210”

This is the list of Fedora bugs filed against nouveau. Maybe when we have some more info, you can go through them to see if any seem familiar. Of course, assuming that this is still the one in use (I’ve given up on Nvidia a while back and so may not be up to date with the software stack):

Bug List: xorg-x11-drv-nouveau

Attached is a picture of where the boot process is stopping

I did try the logs but the last two entries where the successful log when I booted with 5.8.18 on Sunday and the subsequent boot strong text after trying to boot with 5.9.11 so either I’m not finding the right log or the logging hasn’t started yet.

I took a quick look at the nouveau log but didn’t note anything that might be related but will take a more thorough look again. (I know what you mean about giving up on Nvidia - when I got my new desktop the first requirement was no Nvidia graphics!).

@phild You said “other distribution” and listed several 5.9.XX kernels that work.
May I ask exactly what distribution that is? And is it dual boot or is one in a VM?

It seems that the other distribution works well on the same hardware but F32 has a problem so help us see what is different?

1 Like

The other distribution is PCLinuxOS and it is a dual boot situation - no VMs are involved.

Can you check what nouveau driver version it’s shipping perhaps? As @computersavvy says, if we can get an idea of the differences between Fedora and PCLinuxOS, we may be able to narrow the bug down. The kernel boot parameters may also be relevant.

While looking for the [drm] error message, I found a few some really old bugs that may be worth looking at. They apparently include workarounds.

835648 – kernel freeze after [drm] Initialized drm 1.1.0 20060810 on T520 with Quadro NVS 4200M

752613 – Nvidia 100M on Lenovo W520 Wont boot if using Discrete Graphics

913326 – Could not configure common clock" during boot

I checked Synaptic in the other distribution and it is version 1.0.16-10pclos2020.

Not sure if this is what you are looking for as the linux boot parameters (from the grub file)
linux /boot/vmlinuz-5.9.12-pclos1 root=UUID=440f8f4a-f517-491b-a9e5-9c2f1a3e8b66 splash quiet noiswmd resume=UUID=825d53e5-a7f7-4860-93e0-670b525fda53 audit=0 vga=788

While doing some google searching re my problem, I came across the following posting:

Is there encryption involved during the boot of Fedora? Is this applicable to my problem?

Hrm, Fedora seems to still be on 1.0.15?

@t0xic0der: should we be looking at xorg-x11-drv-nouveau, or the kernel module (/lib/modules/5.9.12-200.fc33.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko.xz)? Would you know? I don’t know how things work with Wayland etc. now.

Nothing here stands out. Can you compare it to the Fedora boot parameters?

I think this kind of thing only comes into play if you have encryption (LUKS and all that which I don’t know much about) is in play.

I would suggest two things.

First, yes - we should be looking for xorg-x11-drv-nouveau and I find it abnormal that the version available at our repos is still 1.0.15. The same has not been reported consistently so it might not be the source of error but who knows, maybe the newer updates might have fixed this - something that we have not received yet. :thinking:

Secondly, Wayland has poor performance with any driver before 420 so if you are still using Geforce 210 (which I suspect you are), please stick to X11.

Thirdly, (I know I said I’d suggest two things but here’s the third) - @phild could you switch displays and try to boot via the integrated display adapter should your CPU provide you with the facility? Remember disabling nouveau kernel module loading on boot by adding the nouveau.modeset=0 as the boot parameter and disabling the DRM.

1 Like

@t0xic0der - checked the back of the machine and the only connectors available for a monitor are those on the video card itself so am not able to test the alternate suggestion.

1 Like

I got some time over the weekend and looked into the menu items in the grub ini file further. Re the Fedora items in the grub menu, none of them had any options specified on the linux command line i.e. the line consisted of “linux” and the location of the initr file - nothing else. Checked the pclos options on the linux command lines and as you noted @FranciscoD, none would appear to have an effect of the video driver as per above earlier.

1 Like

I guess step 1 would be to bump this bug again:

I’m not sure if the maintainer is still around—no progress there in a while.

@t0xic0der: the spec looks simple enough, so maybe we could open a PR with the latest version?

Also in general, any Nvidia users here that would like to help co-maintain (or take over maintenance of) the package? I’ll be happy to sponsor folks to the packager group and help them learn the ropes.

1 Like

@t0xic0der was just learning to shoot but he did not know he would get to go to war so soon

I had begun to learn RPM packaging anyway from (Here’s hoping that this is a right guide) in order to bring GitHub - gridhead/sysmon: An intuitive remotely-accessible system performance monitoring and task management tool for servers and headless Raspberry Pi setups. to my COPR. I think I would be able to pick this one up. :slightly_smiling_face:

(Edit - Umm. I am feeling a bit ashamed to ask this but should you have examples of how a good Specfile is written, or about packaging in general - I would really appreciate their links. Thanks.)

There’s a COPR for 1.0.16 if anyone is interested.

@FranciscoD Could you help me get started with what I need to do? Do I get the SRPM from the repo @grumpey marked and check builds against the archs and distros listed?

If you have time can you try,

I don’t have hardware to test this on.

I submitted a PR based on the COPR build, but it didn’t build in the Fedora CI and I’m not sure why. It might be because I can’t update the lookaside cache but not sure.

You can grab the SRPMs and the spec file from the COPR build.


I’m gonna pass due to the very same reason. I do have a Geforce 210 but with the sordid state of affair of the card - I rather not.

1 Like