[I am sending a CC to pkg-systemd-maintain...@lists.alioth.debian.org] On Thu, Mar 23, 2017 at 11:07:14AM +0100, Sven Joachim wrote: > > There might be a third possibility which seems to happen on one of my > systems: the cached_setup_font.sh script does not work correctly when > run during boot by udev. Because this is what I am observing here, I > even added some debug messages to it to see if it is run at all (as > intended by /lib/udev/rules.d/90-console-setup.rules), and indeed it > does run but the font still remains unchanged. > > Manually running /etc/console-setup/cached_setup_font.sh (or > setupcon -f, for that matter) works fine, so I'm a bit at a loss here.
Since systemd makes some configuration of the console, maybe the following scenario might explain what we observe: 1. systemd/udev creates a new console. 2. systemd begins the initialization of this console. 3. udev runs /etc/console-setup/cached_setup_font.sh by the following rule: ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", RUN+="/etc/console-setup/cached_setup_font.sh" 4. Now cached_setup_font.sh and systemd execute in parallel. If cached_setup_font.sh wins, it will configure the console font first and then systemd will load another font. My tests of how systemd works show that it does the following: 1. It reads the curent font of the current console. 2. Then it does some things to the console(s) (configuration). 3. When a new console is created it loads on it the font read in 1. Therefore, it seems to me that if cached_setup_font.sh completes its job before 1. then everything should be ok. And if systemd completes its configuration before cached_setup_font.sh starts its work, then again everything will be ok. However if both work simultaneously things can go wrong. So, if this scenario is possible, a natural question is what can be done in order to make sure the scripts of console-setup do not execute in parallel with systemd while configuring the console. Anton Zinoviev