Same issue here, and not a Framework laptop. HP ProBook with Ryzen 5 5600U.

also present on the framework 13 AMD Ryzen AI 9 HX 370 Radeon 890M

Also present in AMD Ryzen 7 5700U (KDE 6.5)

Seeing the same issue with my Framework 13 AMD 7040 (7840)

Same issue for me on my Framework 16 AMD 7040

CCing Ray for the plymouth angle...

I'm able to reproduce on my Framework 16 and trying to dig into it too...

I wonder if this might be related to a change in systemd 258, because we're seeing weird issues with plymouth + systemd 258 in dracut CI: https://github.com/dracut-ng/dracut-ng/pull/1765

Err... https://github.com/dracut-ng/dracut-ng/issues/1677

I too have this bug and removing rhgb lets me proceed to the gui login screen. Using Fedora 42 i had no issues, but this happened just as i upgraded my system to Fedora 43. 

I'm using a GPD Win Max 2 2025 running a AMD Ryzen AI 9 HX 370

I can confirm this issue doesn't happen on my Framework Desktop AI Max+ 395 (Radeon 8060S)

I have two virtually identical computers (same motherboard, disk etc), but they differ in their CPU

Computer A: AMD Ryzen 7 8700G w/ Radeon 780M Graphics. Affected by this bug after upgrade to Fedora 43
Computer B: AMD Ryzen 5 8500G w/ Radeon 740M Graphics. Not affected by this bug after upgrade to Fedora 43.

I am also running into this on my Minisforum v3 with an AMD Ryzen 7 8840u. Removing rhgb from kernel parameters does in fact mitigate it.

Confirmed that this does not occur on my Framework 12 (which is Intel based).

FW13 AI 370 with 890M iGPU seems to not have this issue (confirmed with another user - don't have this HW myself)

When I overrode dracut to go back to xz compression, everything works properly again. So it's definitely the system booting too fast.

$ echo "compress=xz" > /etc/dracut.conf.d/00-compress-override.conf
$ dracut -f
$ reboot

That was on my Framework 16, FYI

FYI, having this issue occurs only when using an external monitor on my ASUS Zenbook S 14 UX5406SA. When the laptop is booted without any external monitor connected, the problem does not occur.

I see this on my FW16 with F43, wherein `journalctl -b -1 | grep sddm` returns:

> ~~~
> 17:56:08 systemd[1]: Started sddm.service - Simple Desktop Display Manager.
> 17:56:08 sddm-helper[116790]: Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
> 17:56:08 sddm-helper[116790]: pam_unix(sddm-greeter:session): session opened for user sddm(uid=988) by (uid=0)
> 17:56:08 systemd-logind[116474]: New session 'c1' of user 'sddm' with class 'greeter' and type 'wayland'.
> 17:56:08 systemd-logind[116474]: New session '1' of user 'sddm' with class 'manager-early' and type 'unspecified'.
> 17:56:08 (systemd)[116838]: pam_unix(systemd-user:session): session opened for user sddm(uid=988) by sddm(uid=0)
> 17:56:09 systemd[116838]: drkonqi-coredump-cleanup.timer - Cleanup lingering KCrash metadata was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/kcrash-metadata/*.ini).
> 17:56:09 systemd[116838]: drkonqi-sentry-postman.timer - Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/drkonqi/sentry-envelopes/*).
> 17:56:09 systemd[116838]: drkonqi-coredump-cleanup.service - Cleanup lingering KCrash metadata was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/kcrash-metadata/*.ini).
> 17:56:09 systemd[1]: Started session-c1.scope - Session c1 of User sddm.
> 17:56:09 sddm-helper-start-wayland[116863]: "No backend specified, automatically choosing drm\n"
> 17:56:09 sddm-helper-start-wayland[116863]: "Accepting client connections on sockets: QList(\"wayland-0\")\n"
> 17:56:09 sddm-helper-start-wayland[116863]: "kwin_core: Failed to open /dev/dri/card1 device (Device or resource busy)\nkwin_wayland_drm: failed to open drm device at \"/dev/dri/card1\"\nkwin_wayland_drm: No suitable DRM devices have been found\n"
> 17:56:09 sddm-helper-start-wayland[116863]: "QThreadStorage: entry 7 destroyed before end of thread 0x5573ccba9070\nQThreadStorage: entry 1 destroyed before end of thread 0x5573ccba9070\nQThreadStorage: entry 0 destroyed before end of thread 0x5573ccba9070\n"
> 17:56:09 sddm-helper-start-wayland[116863]: Stopping... "/usr/bin/sddm-greeter-qt6"
> 17:56:09 sddm-helper[116790]: pam_unix(sddm-greeter:session): session closed for user sddm
> 18:03:16 systemd[1]: Stopping sddm.service - Simple Desktop Display Manager...
> 18:03:16 sddm[116788]: Signal received: SIGTERM
> 18:03:16 systemd[1]: sddm.service: Deactivated successfully.
> 18:03:16 systemd[1]: Stopped sddm.service - Simple Desktop Display Manager.
> ~~~

I don't know whether https://forum.endeavouros.com/t/drkonqi-coredump-pickup-service-keeps-failing/70040/6?u=rokejulianlockhart is relevant.

I think the KDE team is pretty sure they know what's going on here (it's basically a race; if sddm starts up 'too fast' the graphics device isn't ready for it yet, and sddm currently doesn't have any mechanism to back off and try again later). It's a question of figuring out the best fix at this point.

This is basically a variation of this upstream issue: https://github.com/sddm/sddm/issues/1917

Any idea why it seems suddenly a lot more common? changes in amdgpu?

It's a race condition. Anything that changes timing can influence it.

It's a race specifically with sddm getting loaded because simpledrm loaded. Simpledrm isn't useful on a system that amdgpu already works properly.

Try this as a workaround:

modprobe.blacklist=simpledrm

I've linked the matching Ubuntu bug report for ideas on what can be done in Fedora about this until SDDM team lands a proper solution upstream.

(In reply to Adam Williamson from comment #22)
> Any idea why it seems suddenly a lot more common? changes in amdgpu?

This is happening because we are decompressing and switching from initramfs to the real root faster, and there's also some goofiness from systemd 258 where the seat management is making it busy slightly longer.

There's a patch I'm backporting for kwin that will make it retry when the drm device is not ready yet and that should mitigate most of this, combined with our existing seat0 patch for sddm.

> Try this as a workaround: modprobe.blacklist=simpledrm

FWIW, this didn't work for me on a FW13 with amdgpu - no change in behavior, still just a black screen that required changing TTY to fix.  Removing rhgb did work, but it requires entering the decryption password while log messages spew endlessly.  As with others, this started with the F43 upgrade.

(In reply to Tom from comment #26)
> > Try this as a workaround: modprobe.blacklist=simpledrm
> 
> FWIW, this didn't work for me on a FW13 with amdgpu - no change in behavior,
> still just a black screen that required changing TTY to fix.  Removing rhgb
> did work, but it requires entering the decryption password while log
> messages spew endlessly.  As with others, this started with the F43 upgrade.

I don't think we're using simpledrm at all yet when amdgpu is available.

(In reply to Neal Gompa from comment #25)
> (In reply to Adam Williamson from comment #22)
> > Any idea why it seems suddenly a lot more common? changes in amdgpu?
> 
> This is happening because we are decompressing and switching from initramfs
> to the real root faster, and there's also some goofiness from systemd 258
> where the seat management is making it busy slightly longer.
> 
> There's a patch I'm backporting for kwin that will make it retry when the
> drm device is not ready yet and that should mitigate most of this, combined
> with our existing seat0 patch for sddm.

KWin updates proposed that people can test to see if it helps:

* F43: https://bodhi.fedoraproject.org/updates/FEDORA-2025-f2fe101009
* F42: https://bodhi.fedoraproject.org/updates/FEDORA-2025-ebed8db9ab

> I don't think we're using simpledrm at all yet when amdgpu is available.

Ah I see. Then this is a different cause of the race condition than was observed in Ubuntu.

(In reply to Mario Limonciello from comment #23)
> It's a race condition. Anything that changes timing can influence it.
> 
> It's a race specifically with sddm getting loaded because simpledrm loaded.
> Simpledrm isn't useful on a system that amdgpu already works properly.
> 
> Try this as a workaround:
> 
> modprobe.blacklist=simpledrm

Hi,


On my 'framework 13 AMD Ryzen AI 9 HX 370 Radeon 890M'
I did the following as root:

```sh
echo 'blacklist simpledrm' > /etc/modprobe.d/simpledrm-blacklist.conf
dracut --regenerate-all --force
```

And I got the sddm greeter screen back again.

So this workaround works for me.
Thanx

Rob

oh and a reboot ofcourse
Rob

*** Bug 2408518 has been marked as a duplicate of this bug. ***

We're not supposed to be using simpledrm by default if we have regular drivers available, though...

> We're not supposed to be using simpledrm by default if we have regular drivers available, though...

Is amdgpu and all microcode for it in the initramfs by default?

(In reply to Mario Limonciello from comment #33)
> > We're not supposed to be using simpledrm by default if we have regular drivers available, though...
> 
> Is amdgpu and all microcode for it in the initramfs by default?

It is supposed to be, yes. My local initramfs images have them.

(In reply to Neal Gompa from comment #34)
> (In reply to Mario Limonciello from comment #33)
> > > We're not supposed to be using simpledrm by default if we have regular drivers available, though...
> > 
> > Is amdgpu and all microcode for it in the initramfs by default?
> 
> It is supposed to be, yes. My local initramfs images have them.

If I understood the Plymouth changes with F42, they switched tp SimpleDRM by default; nothing I read indicated this as a Workstation-specific change, so I wonder if that is contributing to the interaction with the faster switch from initramfs:

https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm


Ah, I did find it in the Fedora KDE 42 release announcement too, so it does seem possible:

>System boot times should be faster, as the plymouth system component will no longer load the full graphics driver before showing the system splash screen

https://fedoramagazine.org/whats-new-for-fedora-kde-plasma-desktop-42/

It seems like the options to move forward are either:
 - Further test the Kwin change noted above to retry starting SDDM 
 - Using AMDGPU use as a criteria to revert thedefault for Plymouth or disable simpledrm altogether

Given that the work stems from efforts to speed up the boot process, I can't speak to the preferred choice, but hopefully that is useful info

Out of curiosity, I tried swapping to TTY (CTRL+ALT+F2) during the relative "end" of the Plymouth loading screen, and then switched back to the primary session after it loaded. This did seem to work for getting around the race condition and loaded SDDM. So another potential workaround for folks.

Note that there is another bug with similar symptoms of an all black screen when SDDM should start. That bug occurs with external monitors plugged into laptops. If removing the "rghb" kernel boot parameter doesn't work around this bug for you and you have an external monitor plugged in, you may be hitting this other bug:

https://bugs.kde.org/show_bug.cgi?id=511490