Operating systems provide a range of devices that are kernel virtual terminals. Unlike a user-space virtual terminal, where the terminal emulator program is running as a service, with kernel virtual terminals the terminal emulator program is running inside the kernel.
Linux systems provide kernel virtual terminals on /dev/tty1 to /dev/tty63.
See the linux-vt(4) manual page for details.
FreeBSD systems provide kernel virtual terminals on devices /dev/ttyv0 to /dev/ttyv8.
See the vt(4) and syscons(4) manual pages for details.
OpenBSD systems provide kernel virtual terminals on devices /dev/ttyC0 to /dev/ttyCb.
See the wscons(4) manual page for details.
NetBSD systems provide kernel virtual terminals on devices /dev/ttyE0 to /dev/ttyEb.
Login on such terminals is done with ttylogin services configured to use those devices of course, which can be managed just like other ordinary services.
There is one augmentation to ordinary service management: the preset command uses the ordinary preset file mechanism, but can also read the /etc/ttys file.
In containers, access to the real kernel virtual terminal devices is often prevented by the containerization system, which restricts access to the system's character devices from within the container.
One container convention is to symbolically link the kernel virtual terminal device names to the front ends of pseudo-terminals which the containerization system sets up; /dev/tty1 being a symbolic link to (say) /dev/pts/2 which is the front end of a pseudo-terminal allocated by the containerization system.
Another is to still have the containerization system set up pseudo-terminals, and tell the contained system about them through a container_ttys environment variable.
Both of these are clumsy and quite unnecessary with the nosh toolset.
With the nosh toolset, do not have the containerization system involved at all. Simply use user-space virtual terminals.
ttylogin service management on demand
Enabled ttylogin@ services are started at bootstrap in the ordinary way, as they are wanted-by/ the multi-user target.
However, on Linux such services can be left disabled and instead can be activated on demand by the ttylogin-starter tool.
This utility, for which there is a service bundle allowing one to run it itself as a service, starts ttylogin services, directly, as and when the user switches between kernel virtual terminals.
An X server needs a virtual terminal allocated to it for the same reason that console-kvt-realizer does: interlocking the use of the framebuffer and input event subsystem with the kernel's terminal emulator program.
So if using kernel virtual terminals alongside an X server, either one starts the server directly from a login session on one of those terminals, or one reserves a virtual terminal for the X server.
To do this, one simply disables the service.
(Note that ttylogin-starter, which manually starts services irrespective of their enable/disable state, is incompatible with X servers and console-kvt-realizer and should not be used when they are.)
There are three ways to do this:
With presets:
If the /etc/ttys file is being used for presets, one first presets the service off in that file.
ttyv7 /usr/bin/false teken off secure
Then one uses the external formats conversion mechanism to import that preset.
One writes an ordinary preset with (for example) lines in /etc/system-control/presets/60-ttys.preset saying:
disable ttylogin@ttyv7
Then one applies the preset:
system-control preset ttylogin@ttyv7
Directly, disabling the service in the usual way:
system-control disable ttylogin@ttyv7
This will be overridden should presets be applied across ttylogin@ services, which happens when installing/upgrading some nosh packages.