I've removed [Solved] from the Subject: line as reinstallation doesn't count as a solution, and any evidence is destroyed.
On Thu 08 Dec 2022 at 20:33:58 (-0500), Greg Wooledge wrote: > On Fri, Dec 09, 2022 at 01:19:46AM +0100, email.list...@gmail.com wrote: > > As it turns out I didn't need to but for future use, do you have any tips on > > where one might find documentation about how agetty interacts with the rest > > of the debian startup process? I've searched but the results have been > > scant. > > I don't know all of the pieces either. There are a LOT of them. > > By default, systemd is supposed to run a single getty on /dev/tty1, and > also passively "listen" for activity on tty2 through tty6. Switching > to one of those VTs will cause a getty to be spawned there. NOT switching > to them leaves them with nothing visibly running. > > Before pressing Ctrl-Alt-F3: > > unicorn:~$ ps -ft tty3 > UID PID PPID C STIME TTY TIME CMD > > After pressing Ctrl-Alt-F3: > > unicorn:~$ ps -ft tty3 > UID PID PPID C STIME TTY TIME CMD > root 852799 1 0 20:18 tty3 00:00:00 /sbin/agetty -o -p -- \u > --n > > The number of passively launched getty processes is configurable in > /etc/systemd/logind.conf. I believe it's the NAutoVTs= parameter that > controls this. > > I've forgotten the details of your problem, but if switching to tty2 > gives you a login prompt, but switching back to tty1 does NOT give you > one on tty1, then there must be something going wrong with the getty > that's supposed to be started on tty1 at boot time -- but the passive > gettys controlled by systemd-logind must be working. > > I think the passive ones are controlled by getty@.service (the @ sign is > some kind of wildcard). If I read /lib/systemd/system/getty@.service > I can see > > ExecStart=-/sbin/agetty -o '-p -- \\u' --noclear %I $TERM > > which appears to match the process I'm seeing on tty3: > > unicorn:~$ ps w -ft tty3 > UID PID PPID C STIME TTY STAT TIME CMD > root 852799 1 0 20:18 tty3 Ss+ 0:00 /sbin/agetty -o -p -- > \u --noclear tty3 linux > > I don't know whether the initial getty on tty1 is also controlled by > this service, or by some other service. (I've already logged in on tty1 > and done a "startx", so my whole X session is running on tty1, instead > of a getty.) $ tail -n 3 /lib/systemd/system/getty@.service [Install] WantedBy=getty.target DefaultInstance=tty1 $ This has the effect of installing the symlink /etc/systemd/system/getty.target.wants/getty@tty1.service pointing to /lib/systemd/system/getty@.service, which isn't used at runtime, but sets up the symlink that actually starts the tty1 getty. AIUI it also prevents any /automatic/ (passive) instantiation on tty1. (If you remember back to September, you can prevent the appearance of the tty1 getty with systemctl disable getty@tty1.service, which removes the symlink above. See: https://lists.debian.org/debian-user/2022/09/msg00661.html ) > For grins: > > unicorn:~$ systemctl status getty@tty1.service > ● getty@tty1.service - Getty on tty1 > Loaded: loaded (/lib/systemd/system/getty@.service; enabled; vendor > preset> > Drop-In: /etc/systemd/system/getty@.service.d > └─noclear.conf > Active: active (running) since Thu 2022-11-17 18:05:49 EST; 3 weeks 0 > days> > Docs: man:agetty(8) > man:systemd-getty-generator(8) > http://0pointer.de/blog/projects/serial-console.html > Main PID: 743 (login) > Tasks: 0 (limit: 14198) > Memory: 1.7M > CPU: 48ms > CGroup: /system.slice/system-getty.slice/getty@tty1.service > ‣ 743 /bin/login -p -- > > Warning: some journal files were not opened due to insufficient permissions. > > Ah, right, I configured that noclear.conf file on this system. > > unicorn:~$ cat /etc/systemd/system/getty@.service.d/noclear.conf > [Service] > TTYVTDisallocate=no > > So I guess getty@.service also controls the getty on tty1. I have no idea > why it would stop working. Check your logs (systemctl/journalctl as root) > and see what you can find. > > Even though I'm still not clear on how all this stuff works, I hope some > of this rambling and pasting might be helpful. You and I presumably run our systems with multi-user as the final target. I think the OP had graphical instead, but hadn't installed a DM. That's how I interpret: "After that I installed a bunch of packages that I usually do after a fresh install, one of which was lightdm, and all of a sudden everything works and the problem is gone." which implies they hadn't done this first time around. Somebody might test this on a DM/DE system by removing the DM. I imagine that tty1 will sit there waiting for the DM to appear. Obviously I don't know how one would manage to get this with the d-i, but as the OP appears to have had UEFI/BIOS issues, that might mean that the d-i failed in a manner we haven't been told about. Cheers, David.