Fedora 43 KDE Installation failures on a Thinkpad P1 Gen 6

Ask Fedora
, ,
1

TL;DR: I freshly installed Fedora 43 KDE on a new drive in a new laptop three times but it crashed/hung on boot with a black screen. Installing Fedora 43 Workstation (GNOME) worked. I then installed KDE & SDDM and it has continued to work. Why? What happened with the KDE installs?

Hi. I just had an “interesting” experience with a Thinkpad P1 Gen 6 installing Fedora 43 and I wondered if anyone has experienced anything similar and if there is anything to be learned (I did search first, natch).

So, I just purchased a Lenovo Thinkpad P1 Gen 6 from lenovo.com in the good ole US&A*. It was on clearance. It has a 13th gen Intel i7-13800H and an Nvidia Ada 3500 GPU. (My 13th Gen i7 Dell XPS running Fedora (no Nvidia GPU) has been doing yeoman-like service.)

For several years I’ve noticed there seems to be a legendary aspect to Thinkpads running Linux and I thought I’d try it out myself. My Dell XPSs have been working well but then Dell saw fit to get rid of XPS (before they just resurrected it, after I bought the Thinkpad).

The problem arose when I went to install Fedora. I removed the M.2 drive the laptop came with and installed a new 2TB drive and installed Fedora. Installation was the proverbial breeze, but then when I booted the PC it hung hard with a black screen: no light when I smashed the caps lock key. Not good. I tried bringing up other terminals by hitting every combination of control, alt, shift and function keys I could think of. Nada. Except when I hit the power button again Fedora came back to life and then cleanly shut itself down (what?!). Naturally I went through the power-on boot sequence several times in the hope that something transitory had befallen the machine. Figuring there may be a hardware issue or a bad M.2 drive I removed the bottom panel again and swapped in a second M.2 SSD and gave it another go. Same thing. I tried another fresh installation, this time with Fedora 42 - maybe something had happened with 43 even though it’s working fine on my other machines (although they had been updated in situ)? Same scenario. I then tried installing Debian 12 which I just happened to have lying around on a USB stick. That worked! With KDE too, except only on X11 IIRC. Logging in with Plasma kept bouncing back to the SDDM login screen. I logged in and updated to Debian 13. It continued to work.

So I tried a THIRD M.2 drive and installed Fedora 43 fresh, given that the machine was working fine with Debian (it came with Windows 11 Pro which ran fine for several days on a 500GB M.2 drive too before I decided it was finally time to bite the proverbial bullet and create the vaunted Linux-only laptop, no Windows. That was the the whole idea after all). Same experience with the easy install followed by a black screen and what appeared to be a crash. Finally I got the GNOME variant of Fedora 43 and installed that. It booted, I logged in, it works! Encouraged, and possessed of a new devil-may-care attitude I proceeded to install KDE and SDDM using dnf and rebooted. It has continued to work! No black screen or apparent hard hangs so far.

Why did the KDE version of Fedora 43 fail to boot into KDE - several times! - even when installed clean and with the most vanilla configuration, literally just entering the basic personal details and hitting next for everything? And why did GNOME Fedora work out of the box then continue to work after I’d installed KDE? (Are there any logs that I could somehow fish out without another OS on the machine?) Had the machine actually crashed, or was it in some state that simply had no desktop, no video output, and apparently wasn’t responding when I hit the caps lock key several times in a row? It did wake up only to shut down after I hit the power button again.

My initial theory was that somehow I was running afoul of an Nvidia issue given the black screen, even though the machine is, like all other laptops I’ve installed on, using the iGPU. This supposition was further boosted by noticing a line of text logged to the screen in red when booting that mentioned nouveau but contained very little other info except a couple of simple numbers like 0001,03 but I didn’t note it down at the time.

To see if the Nvidia GPU was working I installed the drivers from rpmfusion,org and glmark2 along with nvidia-smi etc. The iGPU gets around 5500 FPS the first time I ran it but the Nvidia GPU (used with DRI_PRIME=1) gets a solid 60 FPS. Anyone know what’s up with that?

I now have a working Thinkpad running Fedora 43 with KDE and Wayland, but I have noticed some video artefacts - a few lines erroneously displayed in Konsole from time to time when simultaneously playing videos, and a horizontal line occasionally across the top of the Plasma panel when I mouse over it. The panel also refuses to auto-hide no matter what I do.

[ETA] I am a little concerned that I have a Fedora machine that’s now in a somewhat unclean state compared to what I would normally experience with a regular Fedora KDE installation. Should I expect any issues, breakages, or non-standard behavior? This is a new scenario for me with Fedora.

Thanks for any input, thoughts, shared woes, etc..

* When I went to the lenovo website to do a warranty check it told me that the machine was a Chinese product and forwarded me to their Chinese language website. My Chinese is a little, er, non-existent. That promulgated a hasty call to the Lenovo support number, followed by a one hour wait before I gave up. I finally got through a couple of days later. Naturally the support person, in India, also naturally, assured me that everything was kosher. (Not his exact words.)

3

If you installed from the original Fedora 43 KDE ISO, you may have fallen foul of this issue.

Installing the latest KDE packages using dnf will have given you an up-to-date system including the fixes to that issue. (So would an install from the Network Install ISO or from the latest respin ISO, probably.)

4

Thanks! It looks as though the bits on my USB drive are dated October 2025, so that could be a red flag.

The Thinkpad does have an Nvidia GPU installed but the Intel iGPU is the default so the Plymouth handoff issue sounds less likely, and there’s no external monitor. However, the Thinkpad did appear to have crashed hard - no response to hitting caps lock, no ability to start non-graphical session - which is different to what’s reported in the linked article.

I’ll try refreshing the KDE installation with the latest bits and installing over the running OS, keeping user data. The GNOME bits that worked are from January 2026 so that could be a hopeful sign. I suppose in the worst case I can re-do what already worked.

I have successfully installed from the same KDE Fedora 43 USB drive on a similarly equipped 13th gen Intel laptop (no Nvidia GPU) so suspected something with the new device (which is actually a couple generations behind the curve, which is usually good for Linux?)

5

I flashed the USB drive with the latest Fedora 43 KDE bits and reinstalled the OS, keeping user data and exactly the same thing. System starts to boot and then crashes hard.

6

I did manage to catch a red line in the output when booting: something to do with unrecognized JEDEC 1d bytes (capture is blurry; 2nd attempt). The Thinkpad has the latest BIOS (1.39) but I did upgrade the memory to 64GB Crucial DDR5-5600, allegedly the same speed supported from the factory. There are no memory settings in the BIOS so I can’t swap between JEDEC and XMP. The machine appeared to work fine with the upgraded memory when running Windows 11 and Fedora 43 Workstation (GNOME) however, so I’m a bit skeptical. If something as fundamental as memory settings was the issue then it’d be the same issue with Fedora 43 Workstation. I’ve essentially tried 3 versions of Fedora now, one of which worked.

This is frustrating.

7

I swapped the new memory for the original: exactly the same behavior.

8

I swapped out the NVMe SSD for a new one and installed Arch. It’s working: GNOME, Hyprland and KDE.

Just no idea what’s going on with the Fedora 43 KDE installation on this machine.

9

I seem to recall there may have been an issue with booting some machines with f43 kde that was solved by removing rhgb from the kernel command line by editing that from the grub menu. Don’t know if that may be the issue but worth a try and cannot hurt.

10

Thanks. I did see that, but only after I’d managed to boot with Arch (KDE). I have the M.2 drive with the re-broken KDE 43 install so I could give it a try. It has the feel of a video problem given the black screen, but the machine does crash which is unexpected. Also, I don’t believe the usual Nvidia issues can be blamed even though the machine does have an RTX 3500 Ada GPU onboard. That’s not a very typical Nvidia chip for consumer PCs, AIUI, so there could be a non-standard vector. Anyway, when I next get an opportunity to take the machine apart and swap drives I’ll report back.

Actually, I don’t know that the machine crashes: it becomes non-responsive after initial boot - no light on the caps lock key when depressed several times - but when I hit the power button to reboot, Fedora comes back alive and goes into an orderly shutdown as evidenced by hitting escape and seeing the usual kernel log messages. I don’t know if this means that it automatically goes into sleep mode instead of booting but apparently it’s not a disorderly crash.

1 Like
11

I reinstalled the F43 KDE SSD and removed rhgb from the relevant grub line and rebooted. It didn’t change the behavior. Now trying yet another F43 install but I’m not anticipating anything different.

After a couple of system updates running Arch I got similar behavior - black screen at boot, no SDDM login screen, but also the system didn’t crash. It seems there’s something specific to this machine - I’ve had no problems booting Fedora KDE going back to 36 IIRC - and it feels like a race condition. A couple of times I got the black screen, most of the time Arch booted fine. It doesn’t seem to be reliably reproducible.

I ran the machine with Windows 11 Pro which it arrived with, for a week before installing Fedora - basically a burn-in period just to make sure everything was correct. It ran normally with no issues. (I’m not going back to Windows however!)

Since installing Fedora Workstation then adding KDE & SDDM seemed to work the best so far I think I’ll go back to that and hope that whatever the issue is it can be fixed in Linux or a fw update by the next major upgrade. I’m assuming there isn’t an actual hardware error: Windows experience implies not. I can’t believe that the machine somehow plays well with Windows but not Linux (Thinkpads have a good Linux reputation, right?) I am slightly skeptical about the RTX 3500 GPU. AFAIK that’s an atypical config, and the black screen does seem like what happens when the graphics driver isn’t playing well with the rest of the system. That said, it runs the i7-13800 iGPU by default. I can put the BIOS into Hybrid GPU mode or dGPU-only. I haven’t tried dGPU-only because I think that’s unlikely to work, or at least less likely, and things aren’t looking too good as is. Maybe I’ll try it, for completeness.

PS: My preference is to run Fedora on the machine. The detours into Debian and Arch are mostly to attempt to remove the hardware variable.

12

I’ve reinstalled KDE 43 Workstation over the previous installation then installed KDE and SDDM over that. It appears to be working like a charm (again).

One thing I have noticed, and I don’t know how salient this is: with the Workstation install the system boots straight into the Fedora screen, no GRUB menu. Everything else I’ve tried puts you into a GRUB menu first. It’s when transitioning from the GRUB menu to the boot splash screen that the system hangs (if it’s going to; Arch behavior was variable, as mentioned).

I believe GRUB is still being used. I’ve checked the grub.cfg against one from another machine which was installed from a Fedora 43 KDE edition ISO and there’s no difference that I can tell (beyond disk UUIDs and FAT IDs etc.). If however, systemd boot is happening then that would be a significant difference and may go some way to explaining what’s happening?

13

I believe I’m booting using GRUB so changed the timeout from 0 to 5 via efibootmgr and rebooted. There was no change in behavior! The system booted immediately into Fedora without showing the GRUB boot menu. I just re-checked the timeout via efibootmgr: it’s still set to 5 seconds. Curiouser and curiouser, quoth Alice.

14

There was an issue in the past where if there were traces of a previous Arch install on your disk, the installer would assume you wanted systemd-boot rather than GRUB. I think that doesn’t happen anymore. But you can try bootctl status to check, which will tell you among other things what bootloader is in use.

That’s a different setting from the GRUB menu timeout.

The efibootmgr timeout controls how long the BIOS waits before starting GRUB (or whatever the default boot manager is) - i.e. it controls how long you have to press F2 (or whatever) to choose a different boot manager.

The GRUB timeout is controlled by GRUB_TIMEOUT in /etc/default/grub. There’s also a grubenv setting that can hide the menu. See -

All that said, that doesn’t really explain the weird differences you see between a Workstation and a KDE install. On Fedora 43 they use the same installer.

15

Fedora (Workstation/KDE) and Arch are on two physically separate SSDs so this shouldn’t be an issue.

16

Ah, thanks. It’s a red herring as it turns out: GRUB_TIMEOUT is set to 5 on this Thinkpad and also on a Dell XPS that I checked. The Dell was installed clean with F43 KDE and gets the standard GRUB boot menu, the Thinkpad will only work if I install F43 Workstation then install KDE over the top of it (using it right now). The Thinkpad has a 5s timeout in /boot/grub2/grub.cfg but it doesn’t go into the GRUB menu on boot at all. The Dell likewise has the standard 5s timeout in /boot/grub2/grub.cfg. The /etc/default/grub files on both machines are identical, and contain GRUB_TIMEOUT=5.

There are a bunch of other settings in /etc/boot/grub2/grub.cfg controlled by e.g. feature_timeout_style, menu_show_once, menu_auto_hide, menu_hide_ok and so on. GRUB is a dark art at the best of times, and these ain’t they!

I guess I’ll put the efibootmgr timeout back to 0. Interestingly, on previous installations (Debian IIRC) the value set through efibootmgr was non-zero, and I though I’d used that to change the amount of time that the GRUB menu was on screen, but I might have been fooled by a placebo effect.

you may have fallen foul of this issue

I was pointed at that before. I don’t believe it’s the same issue, mainly because not only do I get a black screen with a very small underscore cursor at the top and nothing else (it’s a 4K screen) but the machine actually crashes as indicated by the caps lock light not changing state when I hit the key multiple times. However, strangely enought for a hung machine, if I hit the power button Fedora comes to life to complete the shutdown. So perhaps it’s not crashed but in some strange dormant state that I’ve never seen before where it’s basically asleep or hibernating but responds to the power switch.

All I know is that as of now, and after installing more than half a dozen versions of Linux on at least 3 separate SSDs I have a working machine whereas when I do the standard KDE install - which has always worked previously - I get an unusable machine.

Another slight wrinkle: I added the rpmfusion drivers since the machine has an RTX 3500. I could run glmark2 e.g. on the RTX 3500 but after a while and after installing some other software I now get a seg fault when I try to run glmark2 on the Nvidia GPU. That’s also happened every time I’ve thought I had a working F43 installation. Arch did perform better. I have several machines running Fedora 43 and having Nvidia GPUs from a 3050 to a 5080 and - last time I checked! - they’re all running fine. It seems that there’s something specific about this machine that is not playing well with Fedora & KDE.

17

Well, this is crazy: the GRUB boot menu has been magically restored!

I mentioned in a previous response (above) that the graphics capabilities can be changed in the BIOS between Hybrid (default) and dGPU-only (Nvidia RTX 3500) and that I would try dGPU-only. Just to see what difference it made I just tried it. The machine booted fine and I could run glmark2 which posted ~21,000 FPS whereas when I run it with DRI_PRIME=1 in hybrid mode it reliably posts a solid 60 FPS!

The machine ran (very) hot with only the RTX 3500. I rebooted and changed back to Hybrid GPU mode.

And now, by making at least one of those changes, the standard GRUB menu is being displayed.

This is GRUB alchemy as far as I’m concerned. I should have kept a copy of /boot/grub2/grub.cfg so I could do a diff, but that didn’t occur to me - I didn’t expect making a BIOS change to - presumably - change the GRUB config.

Anyway, I suppose that’s one thing cleared up, albeit unsatisfactorily. Now that I’m back to Hybrid mode, glmark2 once again seg faults. I did try running it under gdb with symbols, but it’s hanging attempting to download redhat symbols. It faults in some nvidia library:

Thread 3 “glmark2:zfq0” received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeb5096c0 (LWP 6219)]
0x00007fffe02d66d9 in ?? () from /lib64/libnvidia-glcore.so.580.119.02

I haven’t managed to get any closer and it’s not clear what I might be able to do if I get closer.

I should create another topic or @JeffV will be putting me to rights. I have no idea if this is a real issue or something to do with this crazy installation I seem to have created.

18

Well, according to the timestamp on /boot/grub2/grub.cfg (Jan 24 15:03), the file wasn’t altered by anyone or anything other than the initial installation. And yet the boot configuration just seems to have been changed. I really have no idea…

19

This has the hallmarks of a race condition: if I laboriously step through glmark2 no segment fault occurs, if I let it go it will.

20

With workstation the grub menu is automatically hidden unless you are dual booting.
To have the grub menu display with every boot the command
sudo grub2-editenv - unset menu_auto_hide should take care of that.
sudo grub2-editenv - list should show the current grubenv settings.

2 Likes
21

Thanks. Now that I have a reliably booting machine (so far), albeit one with something of a Frankensteinian provenance, I’m sticking with it and not doing any more fresh installs, unless I am forced to.

The only known issue I have right now is the above mentioned seg fault when attempting to run glmark2 on the Nvidia GPU, and as mentioned that looks like it’s caused by a race condition inside some Nvidia-specific library that I’ve not managed to step into - I don’t believe symbols are available.