[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#857132: console-setup: additional info needed ?



On Thu, Mar 23, 2017 at 11:07:14AM +0100, Sven Joachim wrote:

> >> > ls -l /etc/console-setup/
> >> 
> >> 	-rwxr-xr-x   1 root root   465 Mar 22 11:20 cached_setup_font.sh
> >> 	-rwxr-xr-x   1 root root   358 Mar 22 11:20 cached_setup_keyboard.sh
> >> 	-rwxr-xr-x   1 root root    73 Mar 22 11:20 cached_setup_terminal.sh
> >
> > Hm, the times of these three are too recent. I can see two possibilities:
> >
> >   1. either the bug no longer exists in this system, in which case we 
> > have to find out what caused these files to be created, or
> >
> >   2. the bug still exists and each time the system boots, it recreates 
> > these three files.  In this case we have to find out the cause of this.
> 
> 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.

This very much hints at a dependency problems, does it not ? 
Does your system exhibiting this behaviour run systemd ?

> 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.

I'll constrain my "fixup" script to "-f" now to see whether
that will consistently fix what I am seeing (IOW whether we
can constrain the problem to font setting, which is likely).

I have sometimes noted the following which seems to suggest
that some dependency may come up late:

Directly after boot, during which no VT switch occurred, I
will see the login manager for KDE. When I now switch to the
first console and then ALT-RIGHT through my other consoles up
until vt6 they don't have a getty running just yet (they show
up as empty black screens). The second round through all of
them exhibit the getty login prompt. This happens only very
rarely but it _does_ come up every so often. This fact does
seem to hint a gettys being spawned in a delayed fashion.

I have observed something else, but only ONCE so far:

After running setupcon to fix the font problem one console
(sitting at the login prompt) did not get the message - it
stayed in the old, wrong font. Re-running setupcon fixed that
console, too. Other consoles - which reset to the correct
font upon the first setupcon invocation - where either logged
in or sitting at the login prompt as well, so it's not
whether they were logged in or not.

Might there be a race between getty spawning and setupcon
running ?

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


Reply to: