This all worked great in openSUSE 15.1. Anybody know what, if anything changed this behavior (maybe systemd’s vconsole service)?
I’ve tried changing kernel parameters found in the vconsole man page, and also adding TTY9 to systemd’s vconsole service file and nothing has been able to get the font set properly on TTY9, only on TTY1. Any help or guidance is greatly appreciated.
I visited the man page, but it is a bit unclear. It says that FONT= configures the concole font, bu it does not explain what the value should be, just a name of a font (and when yes, where and how is that font to be found), or a file name of a file that contains the font (and when yes, what is the path to that file?). or different.
The example shows FONT=eurlatgr, but again what eurlatgr exactly represents is unexplained.
Please, as a side step, note that this is basically wrong. Try to understand more about how the shell works and why there should be escaping there, like:
I tested both on Leap 15.3 and Tumbleweed and in both cases font appears on tty1, tty2 and tty9 (I did not check each console). I can switch to tty9 only after I have written something to it.
On both Leap 15.3 and Tumbleweed systemd-vconsole.service is activated in initrd which means you need to have the correct font there. Check with lsinitrd whether font is present. Try booting without Plymouth and “quiet” option - may be font was loaded but then reset back to default. Try stopping in initrd (see man dracut.cmdline, search for rd.break option) - is font loaded after manually running /usr/lib/systemd/systemd-vconsole-setup?
It works both ways.
While in general it is better to explicitly quote meta-characters, default bash behavior is to pass pattern if if it did not match any file, so end result is the same (except if you happen to have file with string ‘lat-v24b’ in the current directory).
Yes, the OP was lucky that the pathname expansion did result in an unaltered word in this case. But doing things wrong and not even detecting it is the more treacherous.
Well, systemd-vconsole-setup just calls setfont so it is whatever setfont supports. Of course, setfont manual page does not go in great details here as well.
My path was rather conventional. I never did this (as I said as warning), he showed his configuration,so I checked mine. I saw the difference in the absence or not of the suffix. Thus I tried to get a verdict from the man page, which it failed to give. Then I just mentioned what I found in the hope it may help the OP (e.g. by adding/removing the suffix and testing both cases).
I created a new tty by enabling and starting a systemd service:
**erlangen:~ #** systemctl enable --now getty@tty9.service
**erlangen:~ #** systemctl status getty@tty9.service
**●** getty@tty9.service - Getty on tty9
Loaded: loaded (/usr/lib/systemd/system/getty@.service; **enabled**; preset: **enabled**)
Active: **active (running)** since Sun 2022-11-13 12:01:00 CET; 6min ago
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Main PID: 30802 (agetty)
Tasks: 1 (limit: 4915)
CPU: 10ms
CGroup: /system.slice/system-getty.slice/getty@tty9.service
└─30802 /sbin/agetty -o "-p -- \\u" --noclear tty9 linux
Nov 13 12:01:00 erlangen systemd[1]: Started Getty on tty9.
**erlangen:~ #**
Currently the following services are active:
**erlangen:~ #** systemctl list-units --type service '*tty*'
UNIT LOAD ACTIVE SUB DESCRIPTION
getty@tty1.service loaded active running Getty on tty1
getty@tty6.service loaded active running Getty on tty6
getty@tty9.service loaded active running Getty on tty9
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
**3 loaded units listed.** Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
**erlangen:~ #**
All three devices are generated from the same template getty@.service. Thus they show identical behaviour.
Yes, you can edit ‘/etc/vconsole.conf’ if, you really want to but, there’s this instruction in the “vconsole.conf” documentation (Handbook):
/etc/vconsole.conf is usually created and updated using systemd-localed.service(8). localectl(1) may be used to instruct systemd-localed.service to query or update configuration.
After you’ve setup “vconsole.conf” with “localectl”, you usually do not need to restart the systemd “localed” service.
BTW, ‘/etc/vconsole.conf’ usually looks like this « assuming that, you’ve set it up with “localectl”
»:
We have a script that collects networking info and some other useful stuff, that is then imported by a template file that’s spit out on tty9. The template file is named and loaded based on the number of rows/columns (which are obviously changeable via the font size). So if the rows/cols didn’t match, it wouldn’t load the correct template file. It’s like a support page for end-users to utilize if they’re having issues.
Just as an FYI:
Adding the “.psfu” to vconsole.conf did not work - the font still only appeared on tty1.
It is part of my initrd.
I’ve found that the vconsole kernel parameter that malcolmlewis has worked like a charm.
We’re hoping that, you’re activating tty9 by calling “agetty” at boot time with the same parameters that ‘/usr/lib/systemd/system/getty@.service’ uses.
Further TTY information is available from the Kernel source – ‘/usr/src/linux/Documentation/filesystems/proc.rst’ – section 1.7 “TTY info in /proc/tty” …
1.7 TTY info in /proc/tty
-------------------------
Information about the available and actually used tty's can be found in the
directory /proc/tty. You'll find entries for drivers and line disciplines in
this directory, as shown in Table 1-11.
.. table:: Table 1-11: Files in /proc/tty
============= ==============================================
File Content
============= ==============================================
drivers list of drivers and their usage
ldiscs registered line disciplines
driver/serial usage statistic and status of single tty lines
============= ==============================================
To see which tty's are currently in use, you can simply look into the file
/proc/tty/drivers::
> cat /proc/tty/drivers
pty_slave /dev/pts 136 0-255 pty:slave
pty_master /dev/ptm 128 0-255 pty:master
pty_slave /dev/ttyp 3 0-255 pty:slave
pty_master /dev/pty 2 0-255 pty:master
serial /dev/cua 5 64-67 serial:callout
serial /dev/ttyS 4 64-67 serial
/dev/tty0 /dev/tty0 4 0 system:vtmaster
/dev/ptmx /dev/ptmx 5 2 system
/dev/console /dev/console 5 1 system:console
/dev/tty /dev/tty 5 0 system:/dev/tty
unknown /dev/tty 4 1-63 console
If you inspect ‘/etc/ttytype’ – provided by the “aaa_base” package, you’ll find a list of the default terminal device to terminal type mapping.
Whether or not, you’ll have to assign tty9 to a “linux” terminal type is a good question – whether or not that has a effect of the console font behaviour is an open issue …
I did not write this part of the custom OS we’re using, so I went and looked at the script and it looks like openvt is being used to display the template file on VT9. Sorry, these are VTs, I had said TTY. I mean the virtual terminals found by pressing on the CTRL keys, like CTRL+ALT+F9. Sorry if there was any confusion.
The wonderful confusion between “Virtual Console” « AKA: Virtual Terminal VT] » and a TTY (device) and a Pseudo Terminal (PTY) …
But, I suspect that, we knew what you meant –
Simply call “who” from a GUI Console Window – in KDE call “Konsole” –
You’ll see a list of users – assuming that, you have a couple of GUI Console Windows open.
If you’re the only user on the machine with a GUI Desktop open, you’ll see yourself logged into to a Virtual Console (VT) named “tty7” (usually) …
Each GUI Console Windows is connected to a Pseudo Terminal – pts/0 … pts/1 … pts/2 … and so on …
[INDENT=2]If you type “tty” at the GUI Console Window CLI prompt, you’ll notice that the TTY allocated to your GUI Console is ‘/dev/pts/0’ or, ‘/dev/pts/1’ or ‘/dev/pts/2’ or ‘/dev/pts/3’ and so on …
[/INDENT]
And, when you use <Ctrl-Alt-F1>, you’ll be connected to the Virtual Console number one (VT1), which is also “tty1” – as far as Standard Output and Standard Input are concerned.
