sddm user missing in plasma track? | PLASMA ISSUES
HOW TO REPRODUCE
- Downloaded the latest (4636db55) iso
- Successfully installed via ventoy and rebooted
- Edited
system.yaml to change "default-gnome" to "plasma"
- Ran akshara update successfully and rebooted
- Now stuck with only a cursor and no DM
- Ran journalctl and found that sddm user does not exist
FIX
- Created it with useradd -m sddm -s /bin/false
and then usermid -a -G video sddm and ran systemctl restart sddm and it workedSolution:Jump to solution
I was investigating this bug yesterday, and the root cause appears to be
akshara simply discarding the new passwd and group files. Implementing the nss-altfiles module (https://github.com/aperezdc/nss-altfiles) to have separate system variants of those files should be viable, since akshara would then be able to replace those files during updates. I'm implementing this right now.GitHub
GitHub - aperezdc/nss-altfiles: NSS module to read passwd/group fil...
NSS module to read passwd/group files from alternate locations - aperezdc/nss-altfiles
63 Replies
@Rudra
reported a lot lol
FIX (as root):
-
useradd -m sddm -s /bin/false
- usermod -aG video sddm
- systemctl restart sddmGitHub
Update plasma.yaml by Jaoheah · Pull Request #3 · blend-os/tracks
Added two commands to fix issue with plasma track.
Will be merged into the track
I think this needs to be looked at more closely. I just did another
akshara update and noticed in the output that the user does get created with UID/GID 963, but when I open up /etc/passwd, it is nowhere to be found and UID/GID 963 is saned which gets created at UID/GID 962 according to the update output. As a matter of fact, a bunch of them seems offset by 1 so I suspect something weird is happening but I am running out of time to troubleshoot at the moment.
Also I think using /bin/nologin would be more standard and according to the sddm repo's README, the home directory needs to be set to /var/lib/sddm so it would be useradd -m sddm -d /var/lib/sddm -s /bin/nologin if we were to create the user in the system.yaml commands section.Solution
I was investigating this bug yesterday, and the root cause appears to be
akshara simply discarding the new passwd and group files. Implementing the nss-altfiles module (https://github.com/aperezdc/nss-altfiles) to have separate system variants of those files should be viable, since akshara would then be able to replace those files during updates. I'm implementing this right now.GitHub
GitHub - aperezdc/nss-altfiles: NSS module to read passwd/group fil...
NSS module to read passwd/group files from alternate locations - aperezdc/nss-altfiles
This issue's quite relevant: https://github.com/coreos/fedora-coreos-tracker/issues/155
GitHub
Handling of default users/groups · Issue #155 · coreos/fedora-coreo...
We need a way to provide default users/groups which: Exist in the root filesystem when Ignition runs. Can be modified by Ignition. Allows us to create new users/groups on upgrade. (We probably can&...
i was having the same issue a while back with the plasma track
a few days before stable
oh yeah, I remember :(
me too
should've fixed it now, building the new package repo 👍
#💬┃general somebody on tg got a 500 from cloudflaremirrors.com
on Mastodon too; you can now specify
arch-repo: in /system.yaml to use a custom Arch repoyay, i can use blend on my main pc now
lol, I'm just testing it once myself lol
damn ok
we gotta update the iso now
(this option was added yesterday btw)
it still isn't an option in the ISO, but I'll add it to the installer later (for now, I'll have it default to https://geo.mirror.pkgbuild.com/, though not just yet, I'm testing the Plasma fix)
so the latest iso defaults there?
ok
how does it work
as an example
DMs
https://blendos.co/reference/configs/system/#reference added to docs
system.yaml - blendOS
system.yaml config reference
anything special to do for those who were already on the plasma track? I deleted the
sddm user I had created manually and an akshara update did not seem to have recreated it 🤔oh hmm, it should have recreated it; could you perhaps run
sudo akshara update again, and see if /.new.etc/passwd and /.update.rootfs/etc/passwd mention sddm (before rebooting)?Now it did, but with UID:GID 10003:10003 which is above the 1000 level. been out of touch so things might have changed without me knowing but system users used to be created below 1000? it might also cause it to appear in the sddm user list
Also, woukd you know from where the '/var/lib/sddm' folder gets sourced/created/copied? The issue have moved to this folder which now have permissions of the user I had created manuallly (with 973:973) so there are permission issues. I could just
chown -R to get a quick fix but I'm afraid not going to the bottom of it might come back to bite me later 😅oh, that's probably just
systemd-sysusers doing its thing :P
Akshara copies over any directories that don't already exist under /var/lib, so you could just delete it and run sudo akshara update againThanks for the quick reply! Flushed
/var/lib/sddm and we are back on track. But indeed, the sddm user now appears in the sddm user list 😅
Had to remove all references to sddm in /etc/passwd | groups | shadow | gshadow, delete the /var/lib/sddm folder and akshara update again for it to be recreated at 960:960, where it belongs! I miss Linux's pre-systemd idempotency! 😁I guess there is still something wrong here. I just tried to switch to plasma after updating. After updating to plasma and rebooting I'm met with a black screen and no cursor.
can you switch to a terminal via ctrl-alt-f4, for example? (if not try ctrl-alt with another f key, f1 through f7)
if so, login and run
journalctl | grep sddm and spot the first output messages that could point you towards the potential problem
@Dillen if you can't switch, you might also want to boot with your blenOS.iso and fire up a console from it to mount your partition and troubleshoot from thereWhat I noticed is that my mouse is not powered, so I'm not sure if boot even completed.
And no terminal for me.
How world I troubleshoot this from the iso? Am I able to build the system on a mounted partition?
you could at least look at the logs to isolate the problem and might even be able to chroot into the mounted partition modify your
system.yaml and try akshara update form thereHi, I am in the same situation as @Dillen .
/var/log/boot.log ends with
"Starting Hold until boot process finishes up ..."
"Starting Terminate Plymouth Boot Screen"
Any other file to check?
Trying a chroot to update downloads the update.tar.zst and immediately ends with "[error] update failed"
@MajorSauce This seems like another problem, unrelated to sddm user so I think you should open up another support request and put your context in there. I even might be able to try and help you later on tonight when I finish work
Ah, sorry about that, I seemed to have the same exact situation as Dillen (black Screen, no mouse, seem to crash while initializing devices, after a change for the plasma track) and wanted to provide the info you requested.
no worries. not enough info to be sure if dillen's issue is or isn't related yet but from what you have shared you don't seem to get to sddm at all so probably not related to that service or the issue I described above :)
plus, the particular issue I descibed initially being solved some might not be inclined to look here, you have more chance of getting people trying to help on your new unsolved issues :)
is there an sddm user
can you get into tty2 and check
Sorry! I've just reinstalled the distribution and will play with it and wait to see if the plasma track has stabilized before switching..
So I'm having similar issues as Dillen described, though for some reason it has yet to reboot and I've been sitting here with the blank screen and no response for ~10 minutes. I'll boot back into v3 (I have them on separate drives) and I can provide my log file if that helps narrow down the issue
Sorry this isn't super human readable, but I just copied and pasted the log file into this txt. Also if you want me to make a new ticket I'll go ahead and do that
From the log, your boot sequence seems fine, we would need to see systemd's journal.
Once booted, if you can switch to a terminal using CTRL+ALT+F4, log in and run
journalctl --no-tail > /root/journal.log and attach this /root/journal.log to this chatI can't get into a terminal in v4 but I'll grab it from dolphin in v3
is there a way I can run that command from v3 or the live USB?
the system won't have booted so I doubt it
I'll admit I'm still fairly new so there's a lot I don't know. Are there any other files I can grab that might be useful for trouble shooting?
also from the time the second entry was generated in the log I posted I waited 13 minutes and nothing happened, couldn't get a response from the system when using ctrl + alt or adding any of the function keys into the macro, but the system also never shut itself off, it just sat there, blank until I got tired of waiting and hit the reset button on my case.
if you can mount the v4 partition from your booted v3 there might be a way to access the v4 journal by pointing your v3
journalctl --directory {path} So let say you mount the v4 partition to ylur v3 /mnt/v4 replace {path} by /mnt/v4/run/log/journal/{an arbitrary bunch of characters} <- there should be a system.journal file in there. It's a binary file so you can't just open it in a text editor, that's why I have you redirect it with --no-tail > /root/journal.log above
also, as a simple troubleshooting measure, you can make sure you only have one monitor plugged in your GPU when you boot into v4trying with one monitor might not be a bad idea. I'll give that a try real quick
Um... That worked
I instantly got into Plasma
Great :)
it will be easier to troubleshoot now, plugging your extra monitor and opening kde's monitor settings. After that you can save your monitor configuration and apply it to
sddm and you should be good@Dyno Sire, you've gained the level
1So the settings get applied to sddm automatically after saving them on my user or do I need to do something special for it?
you need to do something, gimme a sec im trying to find the right paths to give you
your monitor settings are in
~/.config/monitors.xml
you'll need to make a copy to a place for SDDM (KDE's login manager) to use, its the one I'm looking for at the moment ehehe bear with me 😅No worries. I appreciate the help
I hate this feeling, I have to leave and I'm not sure of what I'm about to tell you ehehe I believe it's
/var/lib/sddm/.config/
maybe just give it a shot and if it doesn't work you can always fall back on arch wiki https://wiki.archlinux.org/title/SDDMlet us know how it went, I'll most likely pop by in a couple of hours. Good luck! :)
So in KDE's settings menu you can apply your Plasma settings to SDDM, but the monitor configurations only apply when sddm is running in Wayland and the default is X11, I've tried updating the one line in the config file but it's write protected so I can't change it even using sudo
I tried changing the sddm behavior through KDE settings to automatically log me in in a Wayland session, but it wouldn't display anything until I unplugged my two additional monitors and rebooted. I'm not sure what else to try but I also need to go to bed. Hopefully this information is useful in some way
I'll try to dig a bit deeper tonight. My guess is that you already are on Wayland (check in a term with
echo $XDG_SESSION_TYPE) and sddm just needs to be aware of your multi monitor setup via a monitors.xml fileI wasn't able to find a monitors.xml file last night, but yes, when I'm logged into Plasma I am using Wayland
while logged in right click on your desktop and open the display configiration window. try to plug one other monitor and see if it appears in that setting window. place them side by side, close the display settings and look if you now have the following file
~/.config/monitors.xmlI remember looking in the .config folder but I don't remember seeing a file by that name. But I can check when I get home in ~5 ish hours
no worries im at work also. let me know if you are able to have a 2nd monitors detected in the display config, if the file wasnt there it might gets created once you set two monitors. if so we'll pick it from there tonite :)
I remember configuring all 3 of my monitors and I had them all working outside of sddm, and when I unplug and then plug them back in they went right back to where I set them to be in the display settings
that is a very good sign
Yeah, I think at this point we just need to figure out how to take the user display settings and apply them to sddm to fix that issue
I'm sure there'll be other issues that keep cropping up 😂
that's what we get for wanting to live on the edge :) my debian is stable as a rock but.... #boring
lol
Yeah, I've got v3 for stable for right now
But once we get this figured out I'll pull that drive out of my computer and have it as a cold spare
going through it, I just realised that while SDDM launches the KDE Plasma desktop in a Wayland session, SDDM itself runs in an X11 session by default, which is confirmed by running
journalctl -u sddm -> sddm[768]: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_WtQZNc -noreset -displayfd 16
Also, from what I gathered, SDDM does not make use of the monitors.xml file, it is GDM that does, sorry for creating confusion around this. (https://wiki.archlinux.org/title/GDM#Setup_default_monitor_settings)
I read that SDDM will load the different configuration files in this order:
/usr/lib/sddm/sddm.conf.d/
/etc/sddm.conf.d/
and
/etc/sddm.conf
and I found a JSON config file in /var/lib/sddm/.local/share/kscreen/control/configs which seems to refer to display by connection name (like DP-1 for the GPU's first Display Port I presume) but not sure SDDM is using it.
but I coudln't find where I might be able to set up some X configuration for the SDDM session to use so far and while it is tempting to try to create a 10-monitor.conf in /etc/X11/xorg.conf.d/, I leave it at that for tonightSo what I discovered last night is if sddm is running in wayland mode you can go to KDE settings and import your display settings to sddm. But that only works in wayland mode and I wasn't able to find a way last night to change the X11 monitor behavior of sddm. Changing sddm from X11 to Wayland is only a one line change in the default.conf file located in /usr/lib/sddm/sddm.conf.d/ but the file is write protected and Wayland support in sddm is still considered experimental so I am not sure what other issues might crop up due to that change.
the temporary workaround that we found last night works fine from what I can tell, and I just did a little testing to see if I can make it less of a pain to implement. at least with my specific monitors and GPU I can turn off all but one monitor before booting and get into sddm, then I can turn the monitors on with no issue, though sddm only displayed on the first two monitors, the third didn't show anything until I logged in