Just performed ‘sudo dnf update’ on my Framework 16. It all ran just fine. When I reboot the system is broken. Startup begins, I can get to grub, but then when booting into KDE fedora - I get the spinning gear, it looks like it’s going to load KDE, but before it does that everything goes black on the screen and nothing happens. I’ve tried several times, over several days, to no avail. I’ve let the thing just sit there for up to an hour to see if it might eventually boot. But it does not.
I have even waited a few days and did another update, which it did updates some things, but that is broken as well. So now I have to use grub to go back two updates to get a successful reboot.
If I go into grub and boot into an earlier update then that works fine.
Now what?? What in the latest updates broke the framework?
I am on Fedora-43, kde spin. It updated to: 6.19.8-200.fc43.x86_64
The hardware is: AMD Ryzen AI 9 HX 370 w/ Radeon 890M
If you got as far as the part where KDE is supposed to load, it has most likely already booted. A boot failure would be at or right after the grub part. I’d assume you had the nvidia card as I have dealt with this issue many times with nvidia driver issues.
Anyway, as Mario said, when you get that black screen, try switching to a VT, log in and restart sddm.
CTRL+ALT+FN+F2(or F3, or F4) to get to a console login. Leave out the FN key if your F key function lock is not on.
sudo systemctl restart sddm
If that fails, you need to troubleshoot further. Try “sudo systemctl status sddm” to see if it’s running or failed, and “journalctl -e” to look through the logs starting as the most recent entries.
Yes…No. Mine does this on random. In my case sudo systemctl restart sddm ends up doing nothing. But if after I got into TTY and log in with user name and password, I type into the Konsole: startplasma-wayland it will boot me straight into my normal GUI Desktop. The only difference is then that it won’t get onto the network straight away. A GUI box comes up where you enter your User password again, which then will let you access the Network/Internet again. I think the GUI box is from the Password Manager. I have tested it and 8 ~ 10 time on a reboot without an update, the login screen will now appear again and behave just like normal.
Updates cause this on mine randomly. Once it was a Kernel update (I used the previous kernel until a new update came through) and often it happens during system file/packages updates.
Try configuring sddm to use Wayland then. This sounds like it could be an Xorg bug (sddm defaults to Xorg even if you use Wayland for your user session).
Bottom Line: I have it working now, although I can’t say why it works really. What I did was edit my GRUB config to remove the ‘rhgb quiet’ directives on the boot command line. I did that so that I could see the boot process and try to catch any red text flying by, lol. Having done that it is now booting up just fine.
Further Info: First thing I did was inspect the journal from one of the failed boots. I say failed boot but as jared_kidd pointed out, the system was actually booting - it was running the WiFi, all the devices were loaded and running, all that jazz. I honestly couldn’t see anything in the journal that game me any hints as to what was failing. I really just wanted to modify GRUB so that it would always come up with the boot menu since I would always need to select one of the working updates from the list. While I was editing it I decided to remove the directives that hid stuff during boot so that I could maybe see something. But that seems to have just caused it to just work. So I wasn’t able to try any of the other potential solutions. Which is kind of too bad as those may have given us more information on what the heck is going on with these Frameworks and the updates.
Note: I have been linux-only for some 10 years now and have never had an issue where an update caused a boot failure on any other of my hardware.
A Side Question: Despite trying to get the GRUB menu to come up by editing the config, it won’t do it. I have: GRUB_TIMEOUT=-1; which is supposed to force the menu to come up. Any idea on why this isn’t working on the Framework (it’s works fine on my non-Framework desktop machine).
Those symptoms kind of sound like you may be loading some legacy graphics framebuffer at boot that conflicts with your modern graphics drivers. But I must admit, I haven’t seen that issue come up for many years now on my own systems.
…sound like you may be loading some legacy graphics framebuffer…
I hear you - but it’s a brand new laptop, with a fresh-from-scratch install of fedora with minimal apps installed - actually I don’t think I’ve installed anything beyond what was in the default install other than the Dropbox deamon. It broke on the first kernel update. And I don’t have a dedicated GPU expansion card in it, it’s just running the ‘stock’ embedded GPU. So…I can’t figure what would be causing it any headaches.
So..except for “GRUB_GFXMODE=1024x768” (used to increase font mode as I barely could read the ones that came as default). Your Grub config should be the same.
So run
sudo nano /etc/default/grub
Use the arrow key to select the lines you need to update and “del” key to delete characters and replace with new ones. Nano is the best editor as its super easy to use.
Ones you have updated it, use the CTRL+O to save your updated config and CTRL+X to exit the editor.
Now run this to update the actual GRUB2 config file
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
To unhide the Grub menu permanent run
sudo grub2-editenv - unset menu_auto_hide
This should get you to a proper working Grub menu during bootup.
It was the auto-hide thing that bit me. I never really delved into grub before. I had thought that the entries in etc/default/grub would really control how it behaved. But now I see there are a bunch of scripts in etc/grub.d and those ‘environment’ variables … all of which interact to finally generate the true grub boot config. I thought the line: GRUB_TIMEOUT_STYLE=menu in etc/default/grub would do it.
I really think you are tickling the race condition I mentioned. There is a bug in upstream sddm about it. Ubuntu is carrying a patch for it in their sddm, I don’t know that Fedora is.
Furthermore if you don’t turn off Xorg support in sddm you can hit an issue with how Xorg handles vblank which doesn’t work well with IPS (a low power state on Strix graphics).
I am not sure if you were talking to me, but I followed your advice anyway to see what happens.
Last reboot before any changes again it threw me into the black screen and I had to log in using TTY and startplasma-wayland.
Not a big deal, but a little bit annoying as it happens randomly.
So: in /etc/sddm.conf.d …..I edited the file: kde_settings.conf
Under “Autologin” Line: “Session=” had nothing next to the “=” sign.
I changed it to: Session=plasmawayland.desktop
Rebooted and now the login screen reappeared again (Hurray). Changed the Login screen background and rebooted again..(Hurray) the new login screen appeared.
So, even if your suggestion wasn’t for me, if finally seems to have fixed a problem that has been haunting me for weeks.
I could believe it - but riddle me this: Why has it never occurred on my other two systems, each of which is running the exact same fedora-KDE spin, and each of which has been updated daily and are running the same kernel and app versions that I now have on the Framework? Why is it only impacting the Framework?
Also - when I put the ‘rhgb’ flag back in I still now no longer have the problem. In fact, I can no longer make the issue occur. For now anyway.
It is as if by simply executing the grub2-mkconfig command it fixed it. That can’t really be true, I don’t think. But I can’t think of anything else I did….
As for why you have only recently seen it - it is highly dependent upon boot timing which anything in boot path (kernel, services, plymouth etc) can change. I don’t use Fedora, but I do use KDE and used to use SDDM and I hit it myself too. I’ve since switched to Plasma Login Manager on Arch and GDM on Ubuntu for various reasons; this race condition and the unwillingness upstream to fix it being one of them.
Reading the github issue you point to I now kinda understand why you are thinking SDDM; and I know enough about systemd to understand what they are saying the issue is. The other two machines I have are older Intel chips so likely just lucky that the timing of the graphics chip being ready and SDDM unit startup works out ok on those (the issue does also call out the Intel graphics being affected as well).
