[EN] New SDDM -- NOT Kernel 6.3.9-1 -- Another new behavior

[hendrikL]

Code: [Select]

cat /lib/systemd/system/sddm.service
[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
# Change this if you want to start sddm in a different tty
Conflicts=getty@tty1.service getty@tty7.service
After=getty@tty1.service getty@tty7.service

After=systemd-user-sessions.service systemd-logind.service
# Workaround entropy starvation
After=haveged.service

# If using tty1 and plymouth, sddm will fail till plymouth stops
# consider using:
## After=plymouth-quit.service
# or to forcefully stop plymouth and start earlier:
## Conflicts=plymouth-quit-wait.service
## After=plymouth-start.service plymouth-quit-wait.service
## OnFailure=plymouth-quit.service

[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStart=/usr/bin/sddm
Restart=always
RestartSec=1s
EnvironmentFile=-/etc/default/locale

[Install]
Alias=display-manager.service

But be careful with the axe, ...

[DeepDayze]

Code: [Select]

cat /lib/systemd/system/sddm.service
[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
# Change this if you want to start sddm in a different tty
Conflicts=getty@tty1.service getty@tty7.service
After=getty@tty1.service getty@tty7.service

After=systemd-user-sessions.service systemd-logind.service
# Workaround entropy starvation
After=haveged.service

# If using tty1 and plymouth, sddm will fail till plymouth stops
# consider using:
## After=plymouth-quit.service
# or to forcefully stop plymouth and start earlier:
## Conflicts=plymouth-quit-wait.service
## After=plymouth-start.service plymouth-quit-wait.service
## OnFailure=plymouth-quit.service

[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStart=/usr/bin/sddm
Restart=always
RestartSec=1s
EnvironmentFile=-/etc/default/locale

[Install]
Alias=display-manager.service

But be careful with the axe, ...

Ugh that gets messy with that axe...

[hendrikL]

More interesting for me is, why the hack on vt2 i see the graphical login, greyed out, and i am not able to do there something!
Ok it is blocked by xorg, if I read following correct,

Code: [Select]

sddm.service - Simple Desktop Display Manager
     Loaded: loaded (/lib/systemd/system/sddm.service; enabled; preset: enabled)
     Active: active (running) since Thu 2023-06-29 14:19:52 CEST; 18min ago
       Docs: man:sddm(1)
             man:sddm.conf(5)
   Main PID: 765 (sddm)
      Tasks: 7 (limit: 14181)
     Memory: 131.8M
        CPU: 827ms
     CGroup: /system.slice/sddm.service
             ├─765 /usr/bin/sddm
             └─843 /usr/lib/xorg/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_reMTJv -noreset -displayfd 16
...


I am asking me, why, if the sddm authentication is on vt2, the graphical target is, after successful login,  on the next vt (vt3) or if I want on vt7 and not vt2,
So I have a graphical artefact on vt2 when I am working with the GUI, this little thing I do not understand.

[orinoco]

First try:

Code: [Select]

# Change this if you want to start sddm in a different tty
#Conflicts=getty@tty1.service getty@tty7.service
#After=getty@tty1.service getty@tty7.service
Conflicts=getty@tty1.service
After=getty@tty6.service
My idea was to recover my well known behavior
* systemd output on tty1 -> reached by Ctrl-Alt-F1
* tty2-tty6 for login on console -> reached by Ctrl-Alt-F2-6
* to jump back to graphical interface with Alt-F7

But no luck:
* systemd output still on tty1 -> as expected
* SDDM still "sits" on tty2 -> boo
* tty3-tty6 free -> better than nothing
* to jump back to graphical interface with Alt-F2 -> boo

Any better idea?

[hendrikL]

not this way.

if you want tty1 (vt1) "free" remove conflict and after getty@tty1.service. Then you have vt1 to work on if you want. and if you want the graphical target on vt7 remove that too, but if that is useful? Maybe it is the best way to shoot yourself in the foot.

I DON'T RECOMMEND TO DO THAT!

[hendrikL]

I made some tests with wayland.

If you have DisplayServer=wayland in the sddm.conf (see man sddm.conf),
it is the best choice to let it as it is or you have to start your graphical session with startx, startplasma-wayland, startplasma-x11 (sddm didn't start), what else going wrong I don't know.

[ro_sid]

@
I am thinking, that in an installed system, the closest thing you can do to achieve

My idea was to recover my well known behavior
* systemd output on tty1 -> reached by Ctrl-Alt-F1
* tty2-tty6 for login on console -> reached by Ctrl-Alt-F2-6
* to jump back to graphical interface with Alt-F7

would be to actually start 6 ttys at boot-time by via:

To add another pre-activated getty, enable and start getty@ttyX.service.

for X in 1 to 6.
For this, it is not even necessary to modify any sddm-setting, it should automatically use tty7/the next tty.
If you do not get a greeter-window, it may be necessary to increase the value of NAutoVTs in /etc/systemd/logind.conf, I did not try it, thus do not know about this. It may also be, that sddm "keeps" tty7 and your graphical desktop becomes tty8.

[GoinEasy9]

Hi all

Today I noticed the same changes happening in my Tumbleweed install. (KDE + sddm)

tty7 --> tty2 and the need to use tty3 instead of tty2 for updates.

At this point I see no reason to be concerned over the changes. I'm just going to have to get used to using tty3. I'm not having any problems with the changes, and, those boot freezes and shutdown problems that some of us blamed on kernel oops seemed to have resolved themselves. Unless some other problems arise ... If it works, don't fix it. :-)

Tom
----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hallo zusammen

heute habe ich die gleichen Änderungen bei meiner Tumbleweed-Installation (KDE + sddm) festgestellt

tty7 --> tty2 und die Notwendigkeit, tty3 anstelle von tty2 für Updates zu verwenden.

Zum jetzigen Zeitpunkt sehe ich keinen Grund, mir wegen der Änderungen Sorgen zu machen. Ich werde mich einfach an die Verwendung von tty3 gewöhnen müssen. Ich habe keine Probleme mit den Änderungen, und die Probleme beim Booten und Herunterfahren, die einige von uns auf Kernel-Oops zurückführten, scheinen sich von selbst gelöst zu haben. Es sei denn, es treten andere Probleme auf ... Wenn es funktioniert, sollte man es nicht reparieren :-)

Tom

[edlin]

I agree with @GoinEasy9 that there is currently no reason for me to change the situation. „Raider is now called Twix - nothing else changes'' And tty7 is now tty2. I can live with it, as I'm sure most users can.

Ich halte es wie @GoinEasy9. Aktuell gibt es für mich keinen Grund, an der Situation etwas zu ändern. „Raider heißt jetzt Twix – sonst ändert sich nix'' bzw. tty7 ist jetzt tty2. Ich kann damit leben, wie sicher auch die meisten Anwender auch.

edlin

[DeepDayze]

I can live with this change and I find it not really a big deal. Wonder what's the rationale behind this particular change.