When I updated to KDE plasma 6.6.0 and the page came up about donating etc I did nothing. On my other two systems I clicked to not show. These systems work fine. On the first system when I log in (especially after some update) plasma won’t open. If I press the power/start key..I get the login /shut down etc screen. I login again and sometimes Plasma will open..might have to do this a couple of times..but eventually it will open.
What do you have in journactl for a failed boot where KDE fails to open?
Compare and contrast for a session that works as expected.
Not an expert.
Lines in red from yesterday’s, Plasma open OK this am
Apr 20 07:30:07 fedora kernel: ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32) (>
Apr 20 07:29:57 fedora systemd[1]: Mounted tmp.mount - Temporary Directory /tmp.
Apr 20 07:30:07 fedora kernel: ACPI Error: Aborting method _SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT) (20250807/pspars>
Apr 20 07:29:57 fedora systemd[1]: Found device dev-tpm0.device - /dev/tpm0.
Apr 20 07:30:07 fedora kernel: ACPI Error: Aborting method _SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT) (20250807/pspars>
Apr 20 07:29:57 fedora systemd[1]: Reached target tpm2.target - Trusted Platform Module.
Apr 20 07:30:07 fedora kernel: ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D008] at bit offset/length 128/8 exceeds size of tar>
Apr 20 07:29:57 fedora systemd[1]: Created slice system-systemd\x2dbacklight.slice - Slice /system/systemd-backlight.
Apr 20 07:30:07 fedora kernel: ACPI Error: Aborting method \HWMC due to previous error (AE_AML_BUFFER_LIMIT) (20250807/psparse-529)
Apr 20 07:29:57 fedora systemd[1]: Starting systemd-backlight@backlight:intel_backlight.service - Load/Save Screen Backlight Brightnes>
Apr 20 07:30:07 fedora kernel: ACPI Error: Aborting method _SB.WMID.WMAA due to previous error (AE_AML_BUFFER_LIMIT) (20250807/pspars>
Apr 20 07:29:58 fedora systemd[1]: Condition check resulted in dev-disk-by\x2duuid-2ae15d2c\x2d46c4\x2d437b\x2db089\x2debb72e097f65.de>
Apr 20 07:30:07 fedora
Try this instead: journalctl -b -1 -p 4
the -1 refer to the previous boot, 0 would be curent boot, -2 would be two boots ago and so on, so you may have to adjust which log you’re looking at to locate a failed start-up
As suggested
Attached is the output
(Attachment Journ_outpt.txt is missing)
If it’s large, feed it to fpaste and post the URL. Not ideal as it vanishes from the pastebin after 24 hours, but at least it gets some eyes for a while.
If it’s small enough just paste it as pre-formatted text using the </> button at the top of the message window.
Tried your suggestion. Spotted this section
Apr 20 09:44:31 fedora systemd[1537]: plasma-kactivitymanagerd.service: start operation timed out. Terminating.
Apr 20 09:44:31 fedora systemd[1537]: plasma-kactivitymanagerd.service: Failed with result ‘timeout’.
Apr 20 09:44:31 fedora systemd[1537]: Failed to start plasma-kactivitymanagerd.service - KActivityManager Activity manager Service.
Apr 20 09:44:32 fedora kdeconnectd[13467]: Bluetooth device is powered off
Apr 20 09:44:37 fedora DiscoverNotifier[13517]: Properties could not be invalidated “org.freedesktop.PackageKit.Offline” QList("Prepar>
Apr 20 09:44:37 fedora Disc
Couldn’t send the whole log. Text files not allow for discuusion group
Thx
OK - let’s dig into that timeout.
Post the output from journalctl --user -u plasma-kactivitymanagerd.service -b -1 as preformatted </> text where that -b -1 is whatever offset to get to the same log you posted here. You should see a few messages from the activitymanager daemon and hopefully one of them tells us what it timed out waiting for.
fdlnx@fedora:~$ journalctl --user -u plasma-kactivitymanagerd.service -b -1
Apr 20 09:43:46 fedora systemd[1537]: Starting plasma-kactivitymanagerd.service - KActivityManager Activity manager Service…
Apr 20 09:44:31 fedora systemd[1537]: plasma-kactivitymanagerd.service: start operation timed out. Terminating.
Apr 20 09:44:31 fedora systemd[1537]: plasma-kactivitymanagerd.service: Failed with result ‘timeout’.
Apr 20 09:44:31 fedora systemd[1537]: Failed to start plasma-kactivitymanagerd.service - KActivityManager Activity manager Service.
Apr 20 09:45:39 fedora systemd[1537]: Starting plasma-kactivitymanagerd.service - KActivityManager Activity manager Service…
Apr 20 09:46:18 fedora systemd[1537]: Started plasma-kactivitymanagerd.service - KActivityManager Activity manager Service.
Apr 20 09:46:18 fedora kactivitymanagerd[14623]: Failed to register with host portal QDBusError(“org.freedesktop.portal.Error.Failed”,>
Apr 20 09:46:18 fedora kactivitymanagerd[14623]: Failed to register with host portal QDBusError(“org.freedesktop.portal.Error.Failed”,>
Apr 20 22:30:29 fedora systemd[1537]: Stopping plasma-kactivitymanagerd.service - KActivityManager Activity manager Service…
Apr 20 22:30:29 fedora systemd[1537]: Stopped plasma-kactivitymanagerd.service - KActivityManager Activity manager Service.
Apr 20 22:30:29 fedora systemd[1537]: plasma-kactivitymanagerd.service: Consumed 26.397s CPU time, 14.8M memory peak.
lines 1-11/11 (END)
Shame - there’s evidently some timeout happening with this daemon and something like the xdg-desktop-portal service/Dbus or the like but debugging it is going to be a nightmare when it’s intermittent.
Perhaps an systemd-analyze blame --user might give us some clues, but really you want to see the output from it when it’s a failing boot, as you don’t care who took a long time to start up when everything works OK and the timeout abort isn’t triggered.
Post it anyway - there might be a smoking gun, but I have little confidence.
Thx for your help..I’ll give it a try next time the issue arises. Well there is hope the issue might go away with Fedora 44
had to login twice
it has more than 10 links
part 1
fdlnx@fedora:~$ systemd-analyze blame --user
40.194s xdg-desktop-portal.service
33.184s plasma-kactivitymanagerd.service
8.361s plasma-plasmashell.service
6.563s plasma-kcminit.service
900ms plasma-powerdevil.service
179ms plasma-polkit-agent.service
177ms plasma-ksmserver.service
157ms plasma-xdg-desktop-portal-kde.service
144ms xdg-desktop-portal-gtk.service
114ms plasma-kded6.service
93ms app-geoclue\x2ddemo[x2dagent@autostart.service](mailto:x2dagent@autostart.service)
84ms app-konqy_preload@autostart.service
74ms app-liveinst[x2dsetup@autostart.service](mailto:x2dsetup@autostart.service)
68ms app-org.kde.plasma\x2dfallback\x2dsession[x2drestore@autostart.service](mailto:x2drestore@autostart.service)
64ms app-org.kde.discover.notifier@autostart.service
61ms app-gnome\x2dkeyring[x2dpkcs11@autostart.service](mailto:x2dpkcs11@autostart.service)
60ms app-at\x2dspi\x2ddbus[x2dbus@autostart.service](mailto:x2dbus@autostart.service)
54ms app-gnome\x2dkeyring[x2dsecrets@autostart.service](mailto:x2dsecrets@autostart.service)
54ms app-gnome\x2dkeyring[x2dssh@autostart.service](mailto:x2dssh@autostart.service)
Part 2
53ms app-xfce4\x2dpower[x2dmanager@autostart.service](mailto:x2dmanager@autostart.service)
52ms app-xfce[x2dpolkit@autostart.service](mailto:x2dpolkit@autostart.service)
52ms app-xfsettingsd@autostart.service
51ms app-org.gnome.SettingsDaemon.DiskUtilityNotify@autostart.service
48ms plasma-restoresession.service
44ms app-imsettings[x2dstart@autostart.service](mailto:x2dstart@autostart.service)
43ms plasma-kglobalaccel.service
41ms app-org.freedesktop.problems.applet@autostart.service
38ms app-org.kde.kdeconnect.daemon@autostart.service
34ms app-org.kde.xwaylandvideobridge@autostart.service
33ms app-org.mageia.dnfdragora[x2dupdater@autostart.service](mailto:x2dupdater@autostart.service)
32ms app-sealertauto@autostart.service
These should be in the 2 to 3 second range. This is almost certainly causing KDE to time out waiting for the xdg-desktop-portal to respond… but you say this only happens occasionally.
The quick fix is to increase the timeout on KDE waiting for xdg-desktop-portal to come up and play ball, but it’s only masking the issue - not fixing the root cause.
The better fix is to ascertain WHY this happens and why only occasionally. Can you post the logs for xdg-desktop-portal.service via journalctl --no-hostname --no-pager --user -b -1 -u xdg-desktop-portal.service assuming the -1 journal is still the one holding this super slow boot. Adjust to suit.
Please post as pre-formatted text - I see you’re replying via email for non-obvious reasons.
Not sure how to post..new to this discussion
fdlnx@fedora:~$ journalctl --no-hostname --no-pager --user -b -1 -u xdg-desktop-portal.service
Apr 22 08:01:37 systemd[1495]: Starting xdg-desktop-portal.service - Portal service…
Apr 22 08:02:07 /usr/libexec/xdg-desktop-portal[1830]: Failed to create settings proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.kde: Timeout was reached
Apr 22 08:02:22 systemd[1495]: xdg-desktop-portal.service: start operation timed out. Terminating.
Apr 22 08:02:22 systemd[1495]: xdg-desktop-portal.service: Failed with result ‘timeout’.
Apr 22 08:02:22 systemd[1495]: Failed to start xdg-desktop-portal.service - Portal service.
Apr 22 08:02:46 systemd[1495]: Starting xdg-desktop-portal.service - Portal service…
Apr 22 08:03:11 /usr/libexec/xdg-desktop-portal[2322]: Failed to create settings proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
Apr 22 08:03:11 systemd[1495]: Started xdg-desktop-portal.service - Portal service.
Apr 22 08:03:51 systemd[1495]: Stopping xdg-desktop-portal.service - Portal service…
Apr 22 08:03:51 systemd[1495]: Stopped xdg-desktop-portal.service - Portal service.
fdlnx@fedora:~$
That confirm that its takes an age to start (over 30 seconds so it times out.)
Doesn’t tell us why though, so the only suggest I have for you is to reinstall both packages which hopefully will reset any default values that may have been changed and reset things. I doubt it though, but one never knows.
sudo dnf reinstall xdg-desktop-portal xdg-desktop-portal-kde
Without some way to reliably trigger this, you’ll never know if you’ve actually fixed the root cause, which in turn makes debugging it somewhat of a tedious process.
If you do want to increase the time-out on KDE waiting, then you can do so with systemctl --user edit plasma-kactivitymanagerd.service and adding…
[Service]
TimeoutStartSec=60
…paying attention to the comment in the file. Adjust the 60 seconds to whatever you deem appropriate. This is not a fix though, more of a bandage so that you cannot see the wound.
Did the reinstall yesterday. Plasma started Ok this am. Then did the updates today. After updates took 4 logouts/logins for Plasma to start. As always after I do an update the issue occurs
Did a clean install of Fedora 44..no longer have that issue