New to Linux in general, but I’ve been enjoying Fedora 42 KDE for some months now, but oh boy, the upgrade experience from 42 to 43 has been horrible.
Discover notified me that i could update to Fedora 43 which i said yes to. Lots of packages needed to be updated first, which i did. After this i could do the upgrade, but now my system wont boot.
I get to GRUB where Fedora 43 is now present, but when i select it i just get a black screen. Fedora 42 is also shown, so i thought selecting that would roll back or something, but this too just shows a black screen.
I’m not even sure where to start. What can i do to get it to boot again or roll back to Fedora 42 ?
Are you able to hit escape after selecting the kernel from the boot menu to show any messages? It could just be the login manager not loading, but if the boot process is proceeding, we should hopefully be able to see the logs. You can also try getting to a virtual console (ctrl + alt + f3/f4/f5).
(We can also try to boot without the gui by modifying the line in the boot menu, but we can try that next)
Also: did the upgrade seem to go fine? Did it get to “complete” and then did it reboot itself?
So hitting escape right after I select the OS, I do get a lot of text output, but it dissapears rather quickly and returns to the black screen where it then hangs again.
I will now attempt the virtual console thing you suggested
So i selected Fedora 43 in grub and began spamming ctrl + alt + f3, f4 and f5.. I then saw a text login screen like on a linux server. But it was flickering with the fedora login screen i know (gui) .. After some seconds it switched to the gui login screen and everything is working again.
But if i reboot i get the black screen again. I tried not spamming the ctrl + alt + f3, f4 and f5 and just went through them slowly, and while it shows me the non gui login screen i cant get it to show me the gui login screen unless i spam the buttons furiously
But at least I’m able to get into Fedora again. Do you have any suggestions why i need to do this virtual console thing?
this sounds rather like https://bugzilla.redhat.com/show_bug.cgi?id=2404966 . if you can figure out how to edit the boot arguments (sorry for the learning curve here…) you can try taking rhgb out and see if that helps? if so, add a comment on that bug with your hardware info, I guess…
Okay so removing rhgb from the boot command fixes it. Its not saved between boots though, so i need to do this everytime, but what does the command even do ?
I will make an entry in the bugreport with some of my specs
I’ve just written a common issues draft which includes a command to make the change permanent. (Thanks to @ngompa for giving me a much more convenient single command than the sequence I’ve had memorized for 20 years). Fedora 43 KDE sometimes boots to a black screen
what rhgb does is give you the graphical boot splash - where you see the Fedora logo as you’re booting up (and if you have an encrypted partition you get a nice graphical passphrase prompt rather than an ugly text one). without it you get a text-based boot process, which is a bit uglier and more jarring. there’s no other consequence, though.
rhgb originally stood for Red Hat Graphical Boot, I think, and was the name of the first thing that implemented graphical boot on RH-family distros. it’s now implemented by something called plymouth, but we kept the kernel arg name…
Alright i can live without the fancyness to get a working system . But thanks for the help! I will mark your comment linking to the bugzilla page as a solution.
I have the same problem as this, and I am currently looking for solutions myself. Just for future reference for anyone else, after pressing Shift during the boot process and selecting the new kernel, you can press E to edit it, and add “nomodeset” to the end of the line which also contains the word “quiet” (sometimes the line ends with “quiet splash”, but mine doesn’t say “splash”). Adding “nomodeset” lets you boot without any video drivers, so you only get the terminal login, but it doesn’t disappear if you do that.
Thank you; that’s useful information. I just tried it with rhgb and nomodeset both removed, and Fedora 43 still didn’t boot for me, so no, removing rhgb didn’t work.
that sounds like you might be hitting a different issue, then. maybe check your logs and see if you see the same messages shown in the bug report, and if there are additional errors from the graphics driver - amdgpu for AMD adapters.
It’s true that I have Gnome rather than KDE, so it could well be different. I don’t know much about what I have installed, and this is bad news for me now because a couple of things I’ve tried have said that stuff has been uninstalled and I’m going to have to reinstall it.
I will check my logs; thank you again. Are these the “dnf system-upgrade log --number=1” logs, or are they somewhere else?
oh, yeah, if you’re on GNOME, you’re almost certainly hitting something else. I’d be looking at journalctl -b on an affected boot (if you can get to a terminal and log in to get it), otherwise boot until the problem happens, then reboot, do whatever you need to do to get to a system, and do journalctl -b1 to get the logs from the previous boot, where the issue happened.
Both my wife (Acer laptop) and I (Asus desktop) had this identical problem occur after a Fedora 42 routine update (about a week ago). None of the above suggestions worked - all ended in a black screen.
I SUSPECT the problem was a corrupt Plasma update, as that is where it fell over in the boot process.
Fortunately, I was connected via ethernet and a dnf distro-sync (last resort after trying everything else suggested) solved the problem by downgrading over 130 updates - many of which were Plasma. Subsequent updates have been OK.
Unfortunately, my wife connects via wireless, which we could not get to connect, no matter what we tried, and we were unable to recover her laptop, necessitating a Fedora 43 complete install (which, I must say, has much improved over the previous Anaconda - it even identified and retained her home drive without asking!)
BTW, asking for output from journalctl and the like was pointless as we could not get the damn things to boot, running in Recovery mode was unable to access these commands
. But thanks for the help! I will mark your comment linking to the bugzilla page as a solution.