No, I don’t use it. But in the “show your desktop” thread, several plasmoids were reported that either don’t work correctly or don’t work at all.
It would be nice if KDE would also release some dev notes about breaking API changes. Alas poor Yorik …
They e.g. removed PlasmaCore.Theme property in 6.6, which many applets use to get theme color information as in PlasmaCore.Theme.textColor. If you see a plasmoid suddenly showing black text on Dark Theme background then that’s probably why.
Ran into that myself.
It broke for me also. I just removed the plasmoid, then opened “syncthing tray” from the application launcher menu and it reloaded the applet correctly.
Yeah, I can I can use the generic tray icon instead of the plasmoid until it is fixed.
It’s really upsetting… this doesn’t work for me at all. All I get is a black screen instead of the new log in screen on reboot
I’ve tried several times and the only way to a working system is to arch-chroot into my broken system and run
sudo systemctl -f enable sddm
to allow logging in using SDDM again. The instructions you provided, just running the one simple command or as @shadow359 wrote:
sudo systemctl disable sddm
sudo systemctl enable plasmalogin
seems idiot proof, so I have no idea what the issue is
I’ve even reinstalled the package, no change.
My Ivy Bridge era Dell laptop does not like plasma-login-manager, but I have no idea why there would be a difference between this new login manager for KDE and the old SDDM
I take it you’ve done this..? ; Plasma 6.6 is in the Extra repo in Arch! - #7 by shadow359
I have done this:
sudo pacman -S plasma-login-manager
sudo systemctl disable sddm
sudo systemctl enable plasmalogin
but not this:
sudo pacman -R sddm-kcm
sudo pacman -R eos-breeze-sddm
sudo pacman -R sddm
I was going to remove those packages after reboot to confirm that plasma-login-manager was working properly. I thought that the disable / enable was enough. Is that my problem?
Not removing the sddm packages was what allowed me to switch back so easily under arch-chroot…
The packages don’t have to be removed. Disabling sddm, enabling plasmalogin and rebooting is enough.
When it fails, login in a different shell (switch with e.g Ctrl+Alt+F5). Login and check the journal for errors, esp systemctl status plasmalogin.service. You can also revert there without chrooting if necessary.
This is a sample from journalctl -u plasmalogin.service:
Feb 18 10:58:23 xxx plasmalogin[880]: Initializing...
Feb 18 10:58:23 xxx plasmalogin[880]: Starting...
Feb 18 10:58:23 xxx plasmalogin[880]: Logind interface found
Feb 18 10:58:23 xxx plasmalogin[880]: Adding new display...
Feb 18 10:58:23 xxx plasmalogin[880]: Using VT 1
Feb 18 10:58:23 xxx plasmalogin[880]: Display server started.
Feb 18 10:58:23 xxx plasmalogin[880]: Socket server starting...
Feb 18 10:58:23 xxx plasmalogin[880]: Socket server started.
Feb 18 10:58:23 xxx plasmalogin[880]: Greeter starting...
Feb 18 10:58:23 xxx plasmalogin-helper[890]: [PAM] Starting...
Feb 18 10:58:23 xxx plasmalogin-helper[890]: [PAM] Authenticating...
Feb 18 10:58:23 xxx plasmalogin-helper[890]: [PAM] returning.
Feb 18 10:58:23 xxx plasmalogin-helper[890]: pam_unix(plasmalogin-greeter:session): session opened for user plasmalogin(uid=956) by (uid=0)
Feb 18 10:58:24 xxx plasmalogin-helper[890]: Starting Wayland user session: "/usr/share/plasmalogin/scripts/wayland-session" "/usr/bin/startplasma-login-wayland"
Feb 18 10:58:24 xxx plasmalogin[880]: Greeter session started successfully
Feb 18 10:58:53 xxx systemd[1]: Started Plasma Login Manager.
Feb 18 10:59:28 xxx plasmalogin[880]: Error from greeter session: "Process crashed"
Feb 18 10:59:28 xxx plasmalogin[880]: Auth: plasmalogin-helper (--socket /tmp/plasmalogin-auth-30a3f2e4-6d18-4798-833b-742acf88c845 --id 2 --start /usr/bin/startplasma-logi>
Feb 18 10:59:28 xxx plasmalogin[880]: Error from greeter session: "Process crashed"
Feb 18 10:59:28 xxx plasmalogin[880]: Auth: plasmalogin-helper exited with 1
Feb 18 10:59:28 xxx plasmalogin[880]: Greeter stopped. PLASMALOGIN::Auth::HELPER_AUTH_ERROR
Feb 18 10:59:28 xxx plasmalogin[880]: Signal received: SIGTERM
Feb 18 10:59:28 xxx systemd[1]: Stopping Plasma Login Manager...
Feb 18 10:59:28 xxx plasmalogin[880]: Socket server stopping...
Feb 18 10:59:28 xxx plasmalogin[880]: Socket server stopped.
Feb 18 10:59:28 xxx systemd[1]: plasmalogin.service: Deactivated successfully.
Feb 18 10:59:28 xxx systemd[1]: Stopped Plasma Login Manager.
so I am getting errors for some reason…
So the the plasmalogin process crashed. I mean there are ways to dig into that further, but at the current time: It’s the first release on day two. Use sddm for now. Let it sit for a month, and see if that crash shakes out by upstream fixes.
Damn son. I guess it’s a cutting edge distro, and unfortunately it’s your turn to bleed ![]()
Does this mean that EOS will now default to plasma-login-manager instead of sddm from the next ISO release?
In a future ISO release but not necessarily the next ISO.
sddm I think
you should also be able to start plasma session without sddm or plasmalogon used: startplasma-wayland after logging in as your user from TTY.. so you do not need to go tha long path to arch-chroot
You are sure system is fully up to date and you do not have testing enabled?
Also what is your GPU and drivers?
inxi -Gaz
I would go save path and leave sddm installed and enabled till you figure out plasmalogin ..
You can manually start / stop both: sudo systemctl stop sddm and sudo systemctl start plasmalogin (stopping sddm will close the Desktop session indeed)
@joekamprad not sure why, but I was unable to enter TTY (Ctrl-Alt F4-F6, and F3 to return to GUI, is working now though
) but I’ll try again next time I test plasma-login-manager if I run into issues again, in case I did it wrong somehow when I was panicking that my GUI was gone ![]()
I was fully up to date, also I don’t have any Testing repos enabled
inxi -Gaz (hope that you find something interesting):
Graphics:
Device-1: Intel 3rd Gen Core processor Graphics vendor: Dell driver: i915
v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports:
active: LVDS-1 empty: DP-1, DP-2, DP-3, HDMI-A-1, HDMI-A-2, HDMI-A-3,
VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0166 class-ID: 0300
Device-2: Microdia Laptop_Integrated_Webcam_E4HD driver: uvcvideo
type: USB rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-1.5:3
chip-ID: 0c45:6449 class-ID: 0e02
Display: wayland server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.9
compositor: kwin_wayland driver: X: loaded: modesetting
alternate: fbdev,intel,vesa dri: crocus gpu: i915 display-ID: 0
Monitor-1: LVDS-1 model: LG Display 0x02df built: 2010 res: mode: 1600x900
hz: 60 scale: 100% (1) dpi: 131 gamma: 1.2 size: 310x174mm (12.2x6.85")
diag: 355mm (14") ratio: 16:9 modes: 1600x900
API: EGL v: 1.5 hw: drv: intel crocus platforms: device: 0 drv: crocus
device: 1 drv: swrast gbm: drv: crocus surfaceless: drv: crocus wayland:
drv: crocus x11: drv: crocus
API: OpenGL v: 4.5 compat-v: 4.2 vendor: intel mesa v: 25.3.5-arch1.1
glx-v: 1.4 direct-render: yes renderer: Mesa Intel HD Graphics 4000 (IVB
GT2) device-ID: 8086:0166 memory: 1.46 GiB unified: yes display-ID: :1.0
API: Vulkan v: 1.4.341 layers: 6 device: 0 type: integrated-gpu name: Intel
HD Graphics 4000 (IVB GT2) driver: mesa intel v: 25.3.5-arch1.1
device-ID: 8086:0166 surfaces: N/A
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor wl: wayland-info
x11: xdpyinfo, xprop, xrandr
And thanks for your reply today and all the support you give!
Wont stopping the plasma-login-manager service by giving the command sudo systemctl stop plasmalogin also kill the KDE desktop session? Also for user planning to take this route, i.e. start the KDE Desktop session using startplasma-wayland after logging into a TTY session, wont it make sense to disable both of these services?
It is a neat trick to have both SDDM/Plasma-Login-Manager disabled, login via TTY terminal and then start the KDE session by giving the appropriate command. I never thought about that. ![]()
Stopping can cause some issues and instability if the current active plasma session was opened through it, otherwise they operate independently. I don’t even have either SDDM or Plasma Login Manager installed on my PC. You can disable SDDM and then restart the system, log in via TTY. This is what I done to test it by initially disabling SDDM since it would be easy to re-enable if I come across any issues at the time, but everything loaded up fine to I ended up removing it.
You can also change the Systemd targeting behavior so it automatically loads straight in to the TTY console login after boot without pressing any hotkeys to enter it normally. To make things easier I set the startplasma-wayland to an alias so I only need to press three characters to start it after logging in.
I was under the impression that login/display Managers like SDDM/GDM and now plasma-login-manager would spawn the DE/WM session and that would be it.
The running DE/WM session would be an independent process and not child of the display manager that launched them.
This is what I suspected too is they are separate from each other. I haven’t actually tried stopping SDDM while the current Plasma session from it is in progress. I read warnings against doing it so I just heeded those warnings on the off chance a problem happens so I disabled and then restarted since I was already restarting for updates at the time. But maybe someone else here knows for definite.