Kernel 5.9 crashes on boot -- how to start troubleshooting?

Discussions in English on using Fedora
,
#1

I am starting a new thread on this, as I haven’t made any headway at all with this.

I have a Dell xp3 13 2020, running Fedora 33. When I upgraded the kernel to 5.9, as a part of the normal uipdate process, on reboot, I get a crazy looking rainbow-pattern screen, which comes up right away, even before I am asked for my password for luks. I can enter the grub menu with . Everything works well on 5.8, which I’ve kept. It has intel Xe graphics, not nvidia, so that’s not an issue.

What I’ve tried, all with the same result:

  • Booting with nomodeset
  • Booting with 1 and 3 options (text console, emergency mode) in grub
  • deleting rhgb quiet in grub
  • Adding rd.break to boot into emergnecy initramfs disk
  • Downloaded last night’s most recent build of 5.10 fromn koji, and installed it—same result.

UPDATE: I was able to boot into 5.9.1 from an Opensuse tumbleweed USB stick.

At this point, I am running out of ideas. about what to try next.

Others with the same machine have not had this problem.

See Dell XPS 13 2020 Fedora 33 hangs on boot after kernel update video issue for previous discussion of this issue.

2 Likes
#2

If this is before you get to grub even, that’s even before the kernel is loaded, right (someone correct me if I’m wrong)?

#3

Gurb is before the kernel is loaded, yes!

I can get to the grub menu if I hit escape while the initial hardware-generated splash screen with the Dell logo is up. If I choose 5.8, everything works as normal. If I choose 5.9, even after editing the grub file with “e” to add nomodeset or the other options I mentioned…haywire!

The normal next step would be for the luks encryption password prompt, but I don’t get to that even, with 5.9.

The crash comes even before any logging begins as I see no evidence of the failed boots when I log back in with 5.8.

1 Like
#4

That sounds like something broke, perhaps with luks encryption. I don’t use that particular bit, so I can’t help here. Perhaps someone else will know. You can also file a bug and speak directly with the maintainers:

Fedora Kernel Bug List

1 Like
#5

Thanks, Francisco! I reported the bug.

3 Likes
#6

Thanks very much. Could you paste a link to the bug here, and we can mark that as the “answer” for this topic to make it easier for people to find too?

1 Like
#7

This was solved. My system configuration was wrong. When I first installed Fedora, I had the SATA mode set to RAID, in the UEFI settings. It should have been set to NVMe. This worked with the 5.8 kernel, but did not with the 5.9 kernel, which is apparently more sensitive to this setting. Subsequent kernel updates and installations used the same configuration options, so testing with Rawhide or other later kernels didn’t work. When I booted into Rawhide live environmment from a USB thumb drive, the system booted as expected. The fix was to reinstall the system from the F33 Live installation media after setting the disk to NVMe in UEFI settings. Subsequent updates to the kernel via Gnome’s Software application have not introduced and new problems.

What tipped me off was that the system failed to boot as soon as the kernel was set to load, and that kernel parameters such as nomodeset did not make any difference. This suggested that there was a problem reading the disk, such as when accidentally deleting a partition near the boot loader can cause misalignment that prevents booting.

The Arch Linux Wiki for the Dell 9300 (https://wiki.archlinux.org/index.php/Dell_XPS_13_(9300)) instructs users to change this UEFI setting.

2 Likes
Dell XPS 13 2020 Fedora 33 hangs on boot after kernel update video issue