So I have installed Rocky 10 on my Lenovo laptop, which has the Ryzen 7 7730 with integrated Radeon graphics. On first boot I got nothing , absolute black screen, went in and set wayland_enable=false so I could use X11 and was able to get Gnome working. Went and installed KDE Plasma and when I switch from Gnome and launch KDE I get nothing but a black screen…
I CAN make Gnome work, but really prefer KDE…
I am thinking that there are issues with Wayland and this particular hardware, but not certain about that.
So now that I have blathered all that…
Not super familiar with Wayland, so how do I get KDE plasma to actually be happy with X11 on this setup?
Unfortunately there is no X11 backend in RHEL10 and thus none in Rocky 10 either. It is wayland only now. If you wnat X11 you will have to install Rocky 9.8 instead. Gnome is using wayland so we know that it is not specifically a graphics card issue.
@dbhosttexas What @jbkt23 says is correct. This was a decision made by Red Hat for their version 10. Rocky follows as closely as possible what Red Hat does.
Okay, so with the GDM config setup the way it is then, why does it come up to the login screen where with that line commented out it doesn’t? And that still doesn’t address why KDE doesn’t show anything but a black screen…
I don’t know what that setting does or where it is implemented. I do recall from other posts that GDM does not play well with KDE and that using KDE’s own display manager may help with your issue. I think some posts in the Rocky forums discuss this issue.
Googled the issue and came up with this grub line to get me into the box since the standard virtual terminals do NOT appear to be working on my box…
1. Add nomodeset to GRUB (Graphics Driver / Wayland Issue)
If your graphics card or hypervisor (such as VMware ESXi) fails to load the default hardware acceleration or Wayland session properly: [1, 2]
Reboot your system and halt at the GRUB boot menu.
Highlight the first boot/installation option and press E to edit the kernel parameters.
Find the line starting with linux and add nomodeset right after the word quiet.
Press Ctrl + X (or F10) to boot with the modified settings. [1, 2]
Once in the box and able to get into a console I was able to vi /etc/gdm/custom.conf and remove the # from the WaylandEnable=false line… Logged out, back in, patched the system reboot and gnome appears to work normally but after installing KDE not so much…
So black screen with sddm installed and sddm.service enabled. Brought it back up with nomodeset and it drops right in, drops me into KDE Plasma once I select it and log in…
Not super familiar with Wayland, sorry about the dumb questions…
Where would I look to determine what is hanging this up. What does nomodeset do?
So doing some digging into journalctl and found the following…
probe with driver amdgpu failed with error 22
Looks like Wayland, and the amdgpu kernel driver do not play well together.
Made certain I had the latest firmware packages installed, and followed the bouncing ball as it were.
Step 1: Boot into Safe Graphics / nomodeset
To fix the issue, you first need to gain access to a usable command line or desktop interface. [1]
Restart your computer and access the GRUB menu (press and hold Shift or tap Esc continuously while booting).
Select your kernel and press e to edit the boot parameters.
Find the line that begins with linux, linux16, or linuxefi.
Move your cursor to the end of that line, add a space, and type nomodeset. [1, 2]
Press Ctrl + X or F10 to boot. (Note: This forces a generic, low-resolution software rendering mode so you can troubleshoot.) [1]
Step 2: Install or Force-Update missing Linux Firmware
If you are running a relatively new GPU (or integrated graphics), your current kernel might lack the correct binary blobs needed to initialize the chip. [1]
Once booted, open a terminal and run a full system update to fetch the latest linux-firmware package:
bash
sudo dnf upgrade --refresh linux-firmware kernel
Use code with caution.
Manually regenerate your initramfs so the kernel loads the correct graphics blobs during the early boot stage:
bash
sudo dracut --force --verbose
Use code with caution.
Reboot normally without nomodeset to see if the driver initializes successfully.
Step 3: Work Around IP Discovery or VBIOS Mismatches
If updating firmware doesn’t fix it, the amdgpu driver is likely choking on your hardware’s power management or IP discovery tables. You can bypass this behavior using specific kernel parameters. [1, 2]
Edit your persistent GRUB configurations:
bash
sudo nano /etc/default/grub
Use code with caution.
Find the line starting with GRUB_CMDLINE_LINUX=.
Try adding one of the following sets of parameters inside the quotation marks (do not include nomodeset here):
Option A (Bypass broken Power Management tables): Add amdgpu.dpm=0
Option B (Enforce Display Core framework): Add amdgpu.dc=1 [1]
Save the file (Ctrl + O, then Ctrl + X).
Rebuild your GRUB configuration file:
bash
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# If booting via UEFI, also run:
sudo grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg
Use code with caution.
Reboot the system.
None of this was helpful. Only thing that gets the box up and happy is booting with nomodeset.
Since you were able to access the logs with journalctl, here is what I use SYSTEMD_COLORS=false journalctl -b --no-pager --grep "amdgpu"
to check for e.g. warnings leading up to the actual error.
In addition, at boot time, kernel line you can remove ‘rhgb’ and ‘quiet’; many people reporting this on ubuntu, but no sensible answers, some say works on previous kernel, but not on this kernel. Are you able to test with external monitor?
A Gnome Wayland session that works while Plasma goes black points at KWin rather than the GPU. After a failed Plasma start, journalctl --user -b current | grep -i kwin shows whether kwin_wayland crashed or never launched, and loginctl show-session <session-id> -p Type confirms which backend the display manager actually started for that seat. Was Plasma installed as the KDE group or as individual rpms?
this is the error that jumps out at me, it sounds like the amdgpu driver (module) is failing to load, you’d expect it to fallback to vga, but it doesn’t. Using ‘nomodeset’ tells it to use vga. If it’s a very new gpu it might not be supported yet.
I was able to get a bit more logging to work around the exact point where it tries to load the amdgpu driver.
Editing the kernel command line, I removed ‘rhgb’ and ‘quiet’ (as above); this didn’t help much, but does show fast scrolling messages before the graphics card tries to switch to high res.
I then tried adding ‘rd.debug’ and ‘initcall_debug’. This did make a difference, showing huge number of messages in journalctl for the current boot, including more amdgpu messages. When checking the journal, it’s important to scroll to the exact moment in time where it tries to load the amdgpu.
On my system it looks like this, the very fist ‘init’ message wasn’t there before, I’d expect this message to appear, even if the amdgpu can’t load
calling amdgpu_init+0x0/0xff0 [amdgpu] @ 536
[drm] amdgpu kernel modesetting enabled
amdgpu: Fetched VBIOS from VFCT
Console: switching to colour dummy device 80x25
amdgpu 0000:09:00.0: vgaarb: deactivate vga console
amdgpu 0000:09:00.0: amdgpu: [drm] Display Core v3.2.351 initialized on DCE 11.2
fbcon: amdgpudrmfb (fb0) is primary device
probe of 0000:09:00.0 returned 0 after 424590 usecs
initcall amdgpu_init+0x0/0xff0 [amdgpu] returned 0 after 415613 usecs
Inserted module 'amdgpu'
Note where the initcall returns (quite slow on my system)
Well, the juggling continues. Just for sh*ts and giggles I went ahead and stabbed Debian 13.7 on the laptop. Booted it up, select KDE Plasma (Wayland) and log in. Working perfectly…
I know RHEL which is what Rocky is based on is intended primarily for servers and not media editing workstations but I am a bit surprised considering this laptop is coming up on 2 years old now… Oh well…
I guess Rocky / RHEL has to remain in VMs for me for a while still…
Well, RHEL doesn’t include KDE by default, and as Rocky is based on RHEL neither does Rocky. KDE comes from the EPEL repository which is a third-party repository so experiences with it working can vary and it’s going to be a bit hit-and-miss. Due to this, it can’t be compared with Debian, since Debian includes KDE in it’s repositories, and since it’s provided in the main Debian repositories the chances of it working are far higher.
I expect had you chosen Fedora with one of their KDE spins it would have also worked perfectly fine like it did with Debian.