Hello everyone,

I cannot get the new Fedora KDE Plasma Desktop 40 ISO to successfully boot (numerous other new F40 ISOs do successfully boot). The screen goes black during the boot-up process and never gets any further. I’ve left several of them sit for 2+ hours with no change to the blank/black screen. Attempts to switch consoles (F2, etc) do not make any change nor seem to have any affect. Review of the VMware.log files do not indicate any particular issue/problem (I can provide some if requested).

This morning I’ve downloaded and verified the Fedora KDE Plasma Desktop 40 ISO via gpgkey verification and that of sha256.

In my environment I’ve several systems with VMware Workstation v17.5.1 where I install, boot and operate the intended target VMs, as follows:

Primary desktop, Win 11 on Supermicro X11-DAI-n motherboard, dual Intel Xeon Silver 4214 CPUs, 256 GB RAM, and dual NVidia graphic cards supporting 2 monitors each

Dell T5500, Centos 8.9, dual Xeon CPUs, 72GB RAM, older NVidia graphic card with a monitor, though most typically are accessed remotely via NoMachine

LG laptop, Win11, I7 CPU, 32 GB RAM

All those systems host various VMs for me, and they are fully updated/patched and recently rebooted within the last 48 hours. LongTerm, on each of these systems I’ll typically have 2-4 VMs booted, running and doing their thing—all without issues/problems.

The Fedora KDE Plasma Desktop 40 ISO will not successfully boot:

On each of these platforms I create a new VM, give it 8GB of RAM, 2 CPUs with 1 core, a 32 GB HD, attach the Fedora KDE Plasma Desktop 40 ISO, and boot up. I’ve attempted configurations of BIOS vs UEFI firmware without any difference in the outcome across all platforms.

I’ve attempted a few othe variations with more RAM, less RAM, more CPUs/cores and less – with no change in the outcome

During several initial boot’s I’ve let the installer verify the integrity of the ISO (it always reached 100% and never complained).

Within VMware Workstation, using the RedSquare to power down the VM is successful and the quasi-booted ISO environment recognized the button action and does the shutdown actions.

In browsing around, I discovered the page for Testing Images Nightly Builds: Fedora nightly compose finder . In there, the KDE Live for Arch x86_64 seems to have several fails last night. The Last known good listed is “ Fedora-Rawhide-20240421.n.0 ”. I’ve downloaded this and experienced the same blank/black screen hang.

If the current edition is deemed ‘broken’ and/or ‘unusable’----will there be a working version posted as an update/replacement?

Is there anything else I can do/attempt to get the current ISO working?

Feel free to point me in the right direction should this group not be the proper place for my posting.

Thank you.
-Joe Wulf

I updated the title to show that the issue is with VMware install.

You may need a VMware update to support the 6.8 kernel.
This has been an issue I have heard about in the past.

I found the following via ‘journalctl -xe’:

Apr 25 04:18:42 fedora systemd[1858]: plasma-ksplash.service: start operation timed out. Terminating.
Apr 25 04:18:42 fedora systemd[1858]: plasma-ksplash.service: Main process exited, code=killed, status=15/TERM
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░ An ExecStart= process belonging to unit UNIT has exited.
░░ The process’ exit code is ‘killed’ and its exit status is 15.
Apr 25 04:18:42 fedora systemd[1858]: plasma-ksplash.service: Failed with result ‘timeout’.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░ The unit UNIT has entered the ‘failed’ state with result ‘timeout’.
Apr 25 04:18:42 fedora systemd[1858]: Failed to start plasma-ksplash.service - Splash screen shown during boot.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░ A start job for unit UNIT has finished with a failure.
░░ The job identifier is 178 and the job result is failed.
Apr 25 04:19:05 fedora maliit-keyboard[2276]: PulseAudioService: pa_context_connect() failed
Apr 25 04:19:05 fedora maliit-keyboard[2276]: PulseAudioService: pa_context_connect() failed
Apr 25 04:19:06 fedora systemd[1858]: Started [email protected] - Launch DrKonqi for a systemd-coredump crash (PID 2435/UID 0).
░░ Subject: A start job for unit UNIT has finished successfully
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░ A start job for unit UNIT has finished successfully.
░░ The job identifier is 509.
Apr 25 04:19:06 fedora drkonqi-coredump-launcher[2942]: Unable to find file for pid 2045 expected at “kcrash-metadata/gnome-shell.d1bc399ba51f4bcaa7107199f31d7fbf.2045.ini”
Apr 25 04:19:08 fedora plasma_waitforname[2624]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Apr 25 04:19:08 fedora systemd[1858]: dbus-:[email protected]: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░ An ExecStart= process belonging to unit UNIT has exited.
░░ The process’ exit code is ‘exited’ and its exit status is 1.
Apr 25 04:19:08 fedora systemd[1858]: dbus-:[email protected]: Failed with result ‘exit-code’.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░ The unit UNIT has entered the ‘failed’ state with result ‘exit-code’.

Joseph C. Wulf:

Interesting about the VMware Workstation upgrade suggestion. I’m currently using the latest (v17.5.1).

It is worth checking with VMware that they have no known issue supporting f40 plasma.
In the past I have needed to wait for a new vmware release to run newer linux releases.
As I am no longer an active vmware user, I do not have current experience.

Barry, I have reviewed some posts over at VMware which mention some of the V17.5.1 issues with Fedora and Wayland. Not necessarily that I understand all of it. But there doesn’t seem to be a VMware Workstation update (beyone v17.5.1) in the near future.

For what it is worth, I can get Fedora 40 Workstation installed without issue. It boots, updates, reboots without issue.

I’ve snapshotted the VM, then followed these Fedora Wiki instrctions to get KDE installed and going: KDE - Fedora Project Wiki . The installation goes like a charm. Switching the Window Manager over to KDE is the downfall. It fails during a subsequent reboot to the black screen as I’ve described.

I’m seeing some messages that talk about X11 deprecation, yet some measure of success when installing/using it on Fedora 40 (not focused on KDE, per se, unfortunatly)… but I’ll look into attempting that route.

Thank you.

Solution is very simple.
VM → settings → display → accelerate 3D graphics.

I have a windows host, VMWare 17.5.1, 1050Ti videocard, and fedora boots just fine.
Without 3D acceleration i have the same problem - just black screen instead of desktop.

Probably, it’s because wayland heavy using graphics.

i’ve upgraded two laptops (lenovo) from 39 to 40 without a problem. both have nvidia gpu’s. both worked with wayland and Xorg. a 3rd upgraded without any problems but ran into the black screen issue (the sddm-on-wayland initial sign-in screen). it’s a dell. for a second, i thought it might have been the graphics acceleration setting. i had it turned off on the one that failed. but turning it on had no effect. the one difference between the two that worked and the one that failed is that the two that worked had only one display while the one that failed had two. hmm…

ah, fixed it. i found /etc/sddm.conf and changed its DisplayServer parameter to have the value ‘x11’. i believe this forces sddm to use x11 to display the login screen before a user sign-in chooses what kind of session to create (which display server to use). everything works now. so it was wayland that caused the problem with my black screen after a reboot.