Description of problem: Upon upgrade to Plasma 5.20 receive black screen when using wayland. X so far appears to work fine, however has some weirdness, i.e. pinned to task manager is blank folder org.kde.discover.desktop. What is that? Currently using X since Wayland is now unusable.
For me, X and wayland works without problems on my optimus system (nvidia + intel) Small bug, - sddm that does not reappear when I log out of my session but the problem was already existing under F31, F32 - And kio-gdrive which does not work 100%. We can now create the google account but the link to gdrive in dolphin does not work. error message: Impossible de créer le module d'entrée / sortie. klauncher a indiqué : Erreur lors du chargement de « /usr/lib64/qt5/plugins/kf5/kio/gdrive.so ».
X appears to work fine. Problem is with Wayland. My system is AMD/Radeon, so that may explain why yours is working. I did try remove the .kde directory and having the system recreate - but that didn't help. I did notice a crash and tried to save it to my disk, but that failed. I just created an empty file named: ksplashqml-20201113-115926.kcrash
I am able to open a terminal window, so if somebody could give me some commands to assist in debugging, I can perform and post the output here. Thanks. I tried stopping and restarting plasmashell, here is the output: $ kquitapp5 plasmashell $ kstart5 plasmashell Omitting both --window and --windowclass arguments is not recommended $ Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running. If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.
Appears to be an issue when using SDDM in conjunction with the 5.20 update. I'm currently using: sddm-0.18.1-8.fc33.x86_64 sddm-themes-0.18.1-8.fc33.noarch sddm-kcm-5.20.3-1.fc33.x86_64 sddm-breeze-5.20.3-1.fc33.noarch When I switch my displaymanager to use GDM, Plasma Wayland no longer experiences the black screen issue.
I just tried with: sddm-kcm-5.20.3-1.fc33.x86_64 sddm-breeze-5.20.3-1.fc33.noarch sddm-0.19.0-1.fc33.x86_64 Same issue, black screen.
Gerald, can you upload the ~/.cache/wayland-errors log file? It may help with further troubleshooting.
Created attachment 1730006 [details] sddm .cache/wayland-errors Hope this helps. If you need me to provide any additional information, LMK. Thanks!
These look like they could be related to the problem: error: : cannot open error: : cannot open error: : cannot open Increasing debug could help figure out this issue, something like this in profile.d would help: QT_MESSAGE_PATTERN=%{if-category} %{category}:%{endif} %{if-debug}%{function}%{endif}%{if-warning}%{backtrace depth=3}%{endif}%{if-critical}%{backtrace depth=3}%{endif}%{if-fatal}%{backtrace depth=3}%{endif} %{message}
That's coming from telegram desktop, so it's not it. Does alt+f2 or alt+space bring krunner? Can you check in coredumpctl if there's something crashing?
Created attachment 1730274 [details] ksplashqml crash on black screen
Just tried with the 5.20.3-2 updates. Same issue. Was able to capture kspashqml crash which I've attached. Cannot open krunner for some reason, but am able to open ksonsole and also ssh into the server.
Can you test remove QML cache dir ? : rm -fr /var/lib/sddm/.cache/sddm-greeter/qmlcache Or Remove other cache in /var/lib/sddm/.cache/ ?
(In reply to Adrien Faveraux from comment #12) > Can you test remove QML cache dir ? : > > rm -fr /var/lib/sddm/.cache/sddm-greeter/qmlcache > > Or Remove other cache in /var/lib/sddm/.cache/ ? I tried both, first removing just qmlcache and then the entire .cache directory. No noticeable effect. Same black screen.
Please post contents of ~/.config/kwinrc too. maybe even try removing that file to see if that helps any. One other user reported that helped them. Also, anything in ~/.cache/wayland-errors file ?
Created attachment 1730992 [details] .config/kwinrc file
(In reply to Rex Dieter from comment #14) > Please post contents of ~/.config/kwinrc too. > > maybe even try removing that file to see if that helps any. One other user > reported that helped them. > > Also, anything in ~/.cache/wayland-errors file ? Removing kwinrc had no effect. Same black screen.
And wayland-errors?
(In reply to Rex Dieter from comment #17) > And wayland-errors? That was posted on November 17th.
(In reply to Gerald Cox from comment #18) > (In reply to Rex Dieter from comment #17) > > And wayland-errors? > > That was posted on November 17th. Sorry you're wanting it from a different location. They shouldn't be using the same name - it's confusing.
Created attachment 1731033 [details] .cache/wayland-errors
A user responding to the ticket on SDDM found a workaround. I've tried it and it circumvents the issue. The question is why would this be needed apparently only when using Radeon, SDDM and Wayland? >>>>>>>> Well, based on this, I just tried editing /usr/share/wayland-sessions/plasmawayland.desktop, replacing the Exec= line with: Exec=/usr/bin/dbus-run-session /usr/bin/startplasma-wayland and not touching anything else. (Then I had to sudo service sddm restart, but simply rebooting would have been also fine most likely...) Now I can log in to Plasma (wayland) just fine from SDDM as well. The original line was: Exec=/usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland That plasma-dbus-run-session-id-needed script contains this: #!/usr/bin/sh # Usage: plasma-dbus-run-session-if-needed PROGRAM [ARGUMENTS] # If the session bus is not available it is spawned and wrapper round our program # Otherwise we spawn our program directly drs= if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ] then drs=dbus-run-session fi exec ${drs} "$@" Perhaps something in this little wrapper goes wrong? Like it detects that dbus-run-session prefix is not needed, even if it is? I haven't tested it any further TBH... <<<<<<<<
This is the KDE bug that created the whack-a-mole situation: https://bugs.kde.org/show_bug.cgi?id=404335
Guessing this is about dbus-broker, though I'm having trouble finding where that was made the default. I *thought* it was f33, but can't find that documented anywhere offhand. The helper script references dbus-run-session (the old one), not dbus-broker-launch, though I believe dbus-broker launches on demand (but don't quote me on that).
(In reply to Rex Dieter from comment #23) > Guessing this is about dbus-broker, though I'm having trouble finding where > that was made the default. I *thought* it was f33, but can't find that > documented anywhere offhand. > > The helper script references dbus-run-session (the old one), not > dbus-broker-launch, though I believe dbus-broker launches on demand (but > don't quote me on that). Yup, they talk about that in the kde bug referenced above. There are also links back to a still opened (for over 2 years) issue on the github site for dbus-broker. As for dbus-broker, looks like in landed in F30: https://bugzilla.redhat.com/show_bug.cgi?id=1557954
Dependent on: https://bugzilla.redhat.com/show_bug.cgi?id=1912046
This problem (at least for me) is being caused because I have the package environment-modules installed. What is curious is why more people aren't experiencing it. Apparently, environment-modules is a fairly pervasive requirement. Are most people that are using KDE Wayland not using SDDM? If you are using KDE Wayland and SDDM, from the investigation so far you should be able to reproduce the issue quite easily. dnf repoquery --whatrequires environment-modules --recursive --installed cheese-2:3.38.0-2.fc33.x86_64 coin-or-Cbc-0:2.10.5-4.fc33.x86_64 coin-or-Cgl-0:0.60.3-2.fc33.x86_64 coin-or-Clp-0:1.17.6-2.fc33.x86_64 digikam-0:7.1.0-1.fc33.x86_64 digikam-doc-0:7.1.0-1.fc33.noarch digikam-libs-0:7.1.0-1.fc33.x86_64 elisa-player-0:20.08.3-1.fc33.x86_64 farstream02-0:0.2.9-3.fc33.x86_64 farstream02-devel-0:0.2.9-3.fc33.x86_64 gmic-0:2.9.4-1.fc33.x86_64 gmic-gimp-0:2.9.4-1.fc33.x86_64 gnome-initial-setup-0:3.38.2-1.fc33.x86_64 gnome-tour-0:3.38.0-2.fc33.x86_64 gstreamer1-plugins-bad-1:1.18.1-2.fc33.x86_64 initial-setup-gui-0:0.3.83-1.fc33.x86_64 kde-connect-0:20.08.1-1.fc33.x86_64 kde-connect-libs-0:20.08.1-1.fc33.x86_64 kde-connect-nautilus-0:20.08.1-1.fc33.x86_64 kde-print-manager-0:20.08.1-1.fc33.x86_64 kde-print-manager-libs-0:20.08.1-1.fc33.x86_64 kdeconnectd-0:20.08.1-1.fc33.x86_64 kid3-0:3.8.4-1.fc33.x86_64 kid3-common-0:3.8.4-1.fc33.x86_64 kwin-0:5.20.4-2.fc33.x86_64 mkvtoolnix-gui-0:51.0.0-1.fc33.x86_64 mp-0:3.1.0-31.20200303git7fd4828.fc33.x86_64 opencv-0:4.3.0-9.fc33.x86_64 opencv-contrib-0:4.3.0-9.fc33.x86_64 opencv-core-0:4.3.0-9.fc33.x86_64 opencv-devel-0:4.3.0-9.fc33.x86_64 picard-0:2.5.5-1.fc33.x86_64 plasma-applet-redshift-control-0:1.0.18-9.fc33.noarch plasma-applet-translator-0:0.7-1.fc33.noarch plasma-desktop-0:5.20.4-2.fc33.x86_64 plasma-integration-0:5.20.4-1.fc33.x86_64 plasma-lookandfeel-fedora-0:5.20.4-1.fc33.noarch plasma-workspace-0:5.20.4-1.fc33.x86_64 plasma-workspace-wayland-0:5.20.4-1.fc33.x86_64 plasma-workspace-xorg-0:5.20.4-1.fc33.x86_64 python3-qt5-0:5.15.0-4.fc33.x86_64 python3-qt5-webkit-0:5.15.0-4.fc33.x86_64 qmmp-0:1.4.3-1.fc33.x86_64 qmmp-devel-0:1.4.3-1.fc33.x86_64 qmmp-plugin-pack-0:1.4.0-1.fc33.x86_64 qmmp-plugin-pack-freeworld-0:1.4.0-1.fc33.x86_64 qmmp-plugins-freeworld-0:1.4.3-1.fc33.x86_64 qt5-qtmultimedia-0:5.15.2-2.fc33.x86_64 qt5-qtmultimedia-devel-0:5.15.2-2.fc33.x86_64 scl-utils-1:2.0.2-16.fc33.x86_64 sddm-breeze-0:5.20.4-1.fc33.noarch stellarium-0:0.20.4-1.fc33.x86_64 telepathy-farstream-0:0.6.1-18.fc33.x86_64 telepathy-farstream-devel-0:0.6.1-18.fc33.x86_64 telepathy-qt5-devel-0:0.9.8-7.fc33.x86_64 telepathy-qt5-farstream-0:0.9.8-7.fc33.x86_64 vokoscreenNG-0:3.0.7-1.fc33.x86_64
That list intrigued me, since I have many of those packages installed, so I investigated why I could remove environment-modules without any problems. If I understand this correctly, the critical "provides" is "environment(modules)", which is also provided by Lmod. (The other component mentioned in bug 1912046.) Lmod is installed on my system, and apparently doesn't cause any issues when starting a session. But if I try to remove it, DNF wants to remove a long list of packages from my system too. If your system is like mine, you could swap Lmod for environment-modules, avoid the black desktop, and only loose scl-utils from the list in comment 26.
(In reply to Göran Uddeborg from comment #27) > That list intrigued me, since I have many of those packages installed, so I > investigated why I could remove environment-modules without any problems. > > If I understand this correctly, the critical "provides" is > "environment(modules)", which is also provided by Lmod. (The other component > mentioned in bug 1912046.) Lmod is installed on my system, and apparently > doesn't cause any issues when starting a session. But if I try to remove it, > DNF wants to remove a long list of packages from my system too. > > If your system is like mine, you could swap Lmod for environment-modules, > avoid the black desktop, and only loose scl-utils from the list in comment > 26. Thank you! You are absolutely correct. That works-around the black-screen issue! However, we're back to whack-a-mole, because Lmod and it's BASH_FUNC has been implicated in: https://bugzilla.redhat.com/show_bug.cgi?id=1754395 Unfortunately, the fundamental root cause issue of https://bugzilla.redhat.com/show_bug.cgi?id=1912046 still exists.
Probably similar cause as bug #1754395 then, I'll followup here too what I found there which may be relavent. So, I've been barking up the wrong tree... with plasma-5.20 upstream decided to write their own environment sync code and not use dbus-update-activation-environment anymore. Some relevant upstream commits: "[startkde] Replace calling dbus-update-activation-environment with native code " https://invent.kde.org/plasma/plasma-workspace/-/commit/1e444c864fc175b3826c88a51a5e2c9f95e497c3 "Syncronise environment to user systemd session" https://invent.kde.org/plasma/plasma-workspace/-/commit/77f418500e56e3227828d26619aeba462a5c8227 There was a bit of validation done in a relatively recent commit, but that probably needs more work then: https://invent.kde.org/plasma/plasma-workspace/-/commit/875bcf1918381873f11eaa286ee3e8780c069676
Interestingly, I tried more to debug/reproduce today (bug #1754395 in particular), and can't seem to possibly since installing systemd-246.7-2.fc33, https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70
(In reply to Rex Dieter from comment #30) > Interestingly, I tried more to debug/reproduce today (bug #1754395 in > particular), and can't seem to possibly since installing > systemd-246.7-2.fc33, > https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70 If you're talking about https://github.com/systemd/systemd/pull/17188 my understanding was that patch was reverted. Lmod only defines: BASH_FUNC_ml%%=() { eval $($LMOD_DIR/ml_cmd "$@") } BASH_FUNC_module%%=() { eval $($LMOD_CMD bash "$@") && eval $(${LMOD_SETTARG_CMD:-:} -s sh) } My understanding was that there was a guard put into place, but the thought now is that it wasn't robust as it needed to be. That's why I created rhbz#1912046 so this issue could be looked at holistically rather than playing whack-a-mole. Try installing: environment-modules-4.5.3-1.fc33 then boot into plasma-wayland using sddm.
worth testing this https://bodhi.fedoraproject.org/updates/FEDORA-2021-ea19dabe82 includes an upstream fix for environment import, which fixes related bug #1754395 at least, may help here too.
(In reply to Rex Dieter from comment #32) > worth testing this > https://bodhi.fedoraproject.org/updates/FEDORA-2021-ea19dabe82 > > includes an upstream fix for environment import, which fixes related bug > #1754395 at least, may help here too. Thanks Rex, this I believe was the patch that David was referring to in SDDM #1335. Appreciate you getting it applied quickly! It circumvents the current issue! I'll comment more in #1912046.
FEDORA-2021-ea19dabe82 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ea19dabe82
FEDORA-2021-ea19dabe82 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.