This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
Please see the Common Issue for solution/workarounds:
Just adding that this not an AMD iGPU only issue, I am using a laptop with Intel 12th gen with Nvidia Rtx 3000 series gpu (I did not have any Nvidia driver installed) and I have same issue.
In scenario 1: I upgraded from F42 to F43 and the above mentioned workaround solved my problem.
Update: After latest kernel update this stopped working. (Maybe not an kernel issue, basically I updated the system and ut stopped working). Now the method in Scenario 2 only works.
Scenario 2: Same machine, same set up, no NVIDIA driver installed, second NVME (both Fedora). In this installation upgraded from F42 to F43 and the above mentioned workaround is not helping. Here I have to go to TTY/runlevel 3, log-in to my account, and then run this command: ‘startplasma-wayland’ to bypass SDDM. And that is working.
In scenario 3: I freshly installed F43 from iso and on first time boot I am stuck in black screen and this time I can not even go to TTY, so basically the installation is bricked. I tried to go to Run Level 3, with no hope.
So anyone with the similar specs as I mentioned above be very careful before fresh installing F43, better to install F42, stay in there or upgrade to F43 and use the workaround.
I have tweaked the description.
I suspect that users seeing this now may be facing a second issue (introduced by Plasma 6.5.1 update over the weekend) rather than (or in addition to) the originally identified one.
e.g. this user sees a symbol lookup error from kwin_wayland, which hadn’t been reported before the weekend and seems akin to the application launcher issue we saw from Saturday.
I faced this issue on a Lenovo Yoga 9i. The only thing that worked for me was updating. None of the solutions in the other threads worked, or they didn’t include full instructions.
I had to edit the boot script to launch in run mode 3 multi user. Press e in the boot menu, find the line that starts with linux, add 3 to the end, press ctrl+x. If I went to the terminal using ctrl+alt+f2 the screen would freeze after the username cursor blinked once; editing the boot script was the only thing that worked for me.
After I got into the tty1 terminal, I had to connect to wifi nmcli device wifi connect "WIFI_SSID" password "PASSWORD"
Then I ran sudo dnf distro-sync
I apologize for the overly verbose instructions. I am just recording them here because I am a novice and didn’t know any of this yet, so hopefully I’ll save another novice some time.
According to your description, it might’ve been a different issue. But It’s great that it works for you now, thanks for sharing.
I have an Acer PH16-71 laptop with an NVIDIA GeForce RTX 4080, and I am experiencing the exact issue described in scenario 3. Removing rhgb and adding 3 to the GRUB boot parameters both failed each time after several fresh installations with the F43 ISO. I believe my only option at the moment is to reinstall F42 and continue using that.
My apologies. I thought it was the same bug because the symptoms were similar
Well, “a black screen on boot” is unfortunately a common problem what can have tens of different causes. Especially for Nvidia users it’s a can of worms, sadly. It’s hard to document some specific issues.
I updated the common issue with another root cause, which is having an external monitor attached:
For anyone also affected (but “slightly differently”), I recommend to test both F43 Workstation and KDE Live images:
a) If you see the problem on both images, it’s not one of these KDE-specific issues. You can file a bug to RH bugzilla, or create a separate topic in Ask Fedora and hope that somebody can help. Also remember that there’s a troubleshooting → safe graphics mode in the Live image menu before boot, which can help to perform the installation (and then you can hope that some updates fix it).
b) If you see the problem just on the KDE image, and you performed all available workarounds and still doesn’t help, you can file a bug in RH bugzilla, or KDE upstream tracker, or discuss here in this topic, and perhaps people can figure out yet another KDE-specific bug to be documented and fixed.
Update, I was able to fix the issue by building my own Fedora 43 KDE live ISO with the latest packages using the vanilla Kickstart configuration, and installing from that instead. I believe this is because KWin was recently patched to work around the SDDM problem, and the currently available Fedora 43 KDE image just doesn’t have it yet.
The live image creation documentation I used was pretty rough, so I’m currently working on a PR to clean it up a bit.
@mystyle48 Do you have any external display attached? Have you tried to boot without it?
If there’s another root cause fixed by the latest kwin, we can recommend people to install from the netinst image, to get latest stable updates immediately. Live respins should eventually be also available, but I’m not sure when.
I am having a seemingly related issue. I am on AMD CPU with no iGPU, NVIDIA 5070TI
Attempted update from Fedora 42 KDE Plasma (with working NVIDIA Driver) to 43, got totally blank screen, no blinking cursor.
I found one workaround suggesting to remove rhgb from boot/kernel arguments, I was able to boot into rescue and run the grubby command to remove it. This gives me a verbose boot log displayed when I try booting fedora.
Boot hangs at plymouth related item. Last two lines of boot:
starting plymouth-quit-wait.service
starting plymouth-quit.service
Other reports mention laptop or AMD iGPU configurations, mine is a different hardware configuration still failing, seemingly related to plymouth.
My bug report: 2413708 – Does not boot. Blank screen. Verbose boot via remove rhgb arg indicates plymouth.
Should I try a network install image?
I did not use any external displays when diagnosing the problem - just the built-in laptop display with the Intel + NVIDIA hybrid GPU setup.
by the way I experienced it too on 7840hs machine, and just had to power off completely and reboot. It happened really rarely and no longer bothered after first several black screens scares, as it was easy to “fix”. But i was sure it was cased by a questionable quality standards of my Chinese laptop brand which had other surprises too.
after upgrading to a newer intel one, not a single black screen yet.
Something much more serious seems to be going on.
I was only
I’m experiencing this failure mode on a desktop computer running with a 7900 XTX for graphics. That computer went from booting into a black screen crash on reboot to consistently booting into a crash regardless of kernel revision used.
The logs include absolutely nothing about the crash, they merely end upon the system attempting to initialize a display.
The only way that I’ve been able to get into the system is:
I did (during the process of figuring this workaround out) get one log entry that provided some tiny tiny context:
Nov 14 18:01:03 localhost kernel: amdgpu 0000:03:00.0: [drm] *ERROR* [CRTC:80:crtc-0] commit wait timed out
Nov 14 18:00:59 localhost kernel: amdgpu 0000:03:00.0: [drm] *ERROR* flip_done timed out
Nov 14 18:00:55 localhost kernel: perf: interrupt took too long (1723617 > 2500), lowering kernel.perf_event_max_sample_rate to 1000
Nov 14 18:00:52 localhost kernel: INFO: NMI handler (perf_event_nmi_handler) took too long to run: 220.623 msecs
Nov 14 18:00:48 localhost kernel: snd_hda_intel 0000:03:00.1: Unable to change power state from D0 to D0, device inaccessible
Nov 14 18:00:43 localhost NetworkManager[1453]: <info> [1763161243.6457] device (enp7s0): state change: ip-config -> ip-check (reason 'none', managed-type: 'full')
Note:
dnf distrosync discrepancy, dnf update --refresh --best --allowerasing reports nothingI also have this annoying issue after some sleep-wake cycle on 1650Ti but with internal AMD graphics as driver.
Fedora 43 is the worst upgrade for my Fedora history till now. Hopefully a working, perma solution will come.
The Fedora 43 respins are out now, so using the updated KDE ISO from there could be a viable solution for those experiencing the same issue I was.
Thanks for info, I updated the common issue description and mentioned it.
Previously when booting up in 42 after an akmod update, I would boot and the graphical display before the login screen would go to the spinning thing. If I then hit esc I could see the plymouth service running. This was because the nvidia kernel module was being built. That would take about two to three minutes time at which point the login screen would come up once that was finished. So I wonder if there is some issue with that. Also I wonder if the nouveau fallback is enabled because even if the Nvidia driver doesn’t work it should still fall back to nouveau. Don’t know if I am on track with this info or not but just wanted to share. The service is called nvidia-fallback.service. I only had it happen once where the fallback occurred and then my son forced the Nvidia graphics driver install and all was good again.
Once again, don’t know if this is useful information or not but just wanted to relay my previous experience.