Laptop Not Booting After Update

I’m using Fedora KDE and I just updated as usual from the KDE store (I do this every weekend, don’t know if that’s a good thing or not). But this time, I can’t seem to boot into my system.

I’m on an AMD 7040 series cpu, Kernel 6.17.5, Fedora 42, and I’m not sure what BIOS version I’m on.

The system starts as usual, but after I pick a kernel (I tried all the normal ones, none work) the loading screen with the framework and fedora logo appear, disappear, appear again, and then disappear. After this, it stays as a black screen indefinitely until I hit the power button. The logos appear again, and the spinning loading icon is still running, and then the system shuts down.

I still have access to the rescue kernel, but I have no idea what to do from here. Any help would be greatly appreciated.

Thanks in advance.

This sounds like the race condition with sddm and simpledrm. If I’m right - the proper solution is to address it in sddm. Gnome hit something similar a year or so back.

Try to use modprobe.blacklist=simpledrm on kernel command line for a workaround.

1 Like

Here is the bug report for it.

1 Like

Hello! Thanks for the reply, before I try the workaround, I would like to ask for some clarifications.

By Kernel command line, do you mean the command line accessed through pressing ‘e’ in the grub menu and then pressing ‘ctl+c’?

Yes. That’s correct.

Ok, thanks for all the help! I’ll let you know how it goes!

Hello again, I’m not quite sure how to get the command to work, I typed it in as written but nothing happened, and when I tried to add Sudo behind it the terminal said it didn’t recognize the ‘sudo’ command.

Should I instead try to type it in the command line accessible before pressing ‘ctl+c’?

Hello, I have run the command under the original kernel terminal, nothing has changed

I read that I could delay the beginning loading screen by removing ‘rhgb’ and ‘quiet’ from the Kernel Terminal, which could solve the race condition, is this a good idea?

Update: Tried multiple ways to remove simpledrm, to no avail. I tried using ‘initcall_blacklist=simpledrm_platform_driver_init’ the loading screen only appeared once this time before going to the black screen

I have a video from when I disabled rhgb and quiet, is there any way to post the video here for others to review and hopefully diagnose the problem?

Simple Drm is one reason for the race condition. There is a second. On the redhat bug there is a potential workaround. Can you try that?

Are you referring to the GitHub you sent? I can’t seem to find any mention of redhat there

I have the same issue

1 Like

Thanks! I’m going to try to install the Kwin update. I’m having trouble chrooting into my system from a liveusb, so is it possible to run the update from the rescue kernel? The rescue kernel is from Fedora 39, so I’m afraid that might cause issues

Update: I tried to boot without rhgb disabled and recorded the results. I noticed that ucsi-acpi USBC000:00 is returning:

unknown error 0

GET_CABLE_PROPERTY failed (-5)

It then also returned

unknown error 256

GET_CABLE_PROPERTY failed (-5)

Despite these errors everything continues as normal, even up to Plymouth quitting itself (which I think is normal). It’s right after Plymouth quits that everything goes black, I’m not sure whether this is related. What should I do now?

I suggest booting with nomodeset and getting update installed then rebooting.

Thanks! Just to be clear, you are referring to the Kwin update and not a complete system update, right?

Yeah I’m talking about the potential fix; the kwin update. But you can use this strategy for any update that prevents boot and is tied to graphics.

Ok, I understand! Sorry I keep asking questions, but how risky would this operation be for my file system? Like my updates, I back up my files weekly, but I just started a new project this week and I’m afraid I’ll lose all that progress

Running with nomodeset is just like booting normal, but without graphics acceleration. Running an update like this is no more dangerous than without.

Understood, I may attempt to back up some critical files before I try anything else then