Correction, the side effect in question is from #systemd, when I create a dummy getty@tty1.service with this an
ExecStart=-/bin/sh -c 'trap "exit 0" SIGTERM; while true; do sleep 1; done'

a following start of sddm.service also succeeds. So #agetty is not who causes this surprisingly hard to identify side effect.
(tested together with having set all of the same flags using stty manually beforehand)

Anyone a clue what else changes on a system just through "systemctl start getty@tty1.service; sleep 10s; systemctl stop getty@tty1.service" that wouldn't show up within "stty -aF /dev/tty1"?

#tty #agetty #systemd

Interestingly it's none of the obvious things that #agetty aka getty@tty1.service is doing.
Even though stty reports differences in the flags for before and after it executes, just setting the exact same flags after a reboot manually isn't enough to get sddm.service to start.

So it's some wird side effect that doesn't show up within stty but persists even after agetty terminated. :/

Maybe `agetty` for the initial login prompt and then `login` for the actual session?
#agetty #linux #terminal

Ich versuche seit ein paar Stunden vergeblich, eine serielle Terminal-Verbindung von meinem Laptop zu meinem headless #Debian-Mini-Server mittels USB-to-Serial-Kabel zu etablieren.

Auf dem Server läuft #agetty, auf dem Lapop #minicom oder #picocom. Die Devices sind alle zugreifbar, die Baudrate und sonstige Parameter sind identisch.

Muss ich vielleicht wie früher ein explizites Nullmodem bzw. X-Modem-Kabel verwenden? Hätte gedacht, die USB-Dinger erkennen das automatisch.