You are not logged in.
Hi all,
I just did a fresh reinstall onto a thinkpad x220, and am experiencing a weird problem that I need help debugging. I'm running dwm without a display manager, just calling startx via .bash_profile after login. When I boot the machine, the login screen shows the Linux kernel version, but the tty is not shown and instead is indicated by a dash. The output looks like this:
Arch Linux 5.15.11-arch2-1 (-)
xinkpad login: _
When I change to a different tty via ALT-SHIFT-Fx, the system will hang for about 5 seconds and then switch to the next tty, with the same kernel information and dash (-) for the tty identifier. When I login to dwm normally and then kill dwm, again the system hangs for about 5 or 6 seconds before presenting the login interface with the dash for the ttyl identifier.
I tried changing to the LTS kernal to see if that may help, but no change. I can also see from the logged output in journalctl gettty@ttyX.service what looks like normal activity, but I am not experienced enough to know where to go next.
One more thing that may be helpful: the output of the command tty shows one result:
/dev/pts/1
Any help would be greatly appreciated.
Thanks!
Last edited by xinkpad (2021-12-28 05:15:46)
Offline
Offline
So these really are two separate issues, and there are open github issues to track them.
github.com/systemd/systemd/issues/21889 - delay when starting new TTY
github.com/systemd/systemd/issues/21919 - tty device name shwon incorrectly on login prompt.
For the delay issue, a workaround has been identified by Joan Bruguera. Here's his post from 21889 explaining the workaround, which I've confirmed works on my own system:
//Note the delay when launching the TTY, is the 5s timeout from Type=idle units:
// Type=
//
// Behavior of idle is very similar to simple; [...] Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway.
//
//Additionally, an easy way to work around the delay without patching systemd is to change the service type of getty to simple, i.e. do systemctl edit getty@.service and type:
//
//[Service]
//Type=simple
Offline
The delay problem is fixed for version 250-4 of the systemd package, which is now available from the [testing] repositories.
Jin, Jîyan, Azadî
Offline
Name resolving has been fixed upstream, as well
Offline
the fix was added to archlinux util-linux package, ttys are identifiable again.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline