Re: hangs at boot
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.lists81@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.
Reply to: