Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Not reproduceable

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Restarting /etc/init.d/console-setup.sh helps, renaming console-setup.sh to
console-setup doesn't.

   * What was the outcome of this action?

After /etc/init.d/console-setup.sh restart, everything is fine.

   * What outcome did you expect instead?

Not to do the restart.

*** End of the template - remove these template lines ***

Hello Thomas,

i saw similar problems with console not being set up correctly.
Take a look into '/etc/console-setup/', all files in there should be 644.

% l /etc/console-setup/*.gz
-rw-r--r-- 1 root root 2,4K  2016-03-12 17:23
/etc/console-setup/cached_Lat15-Fixed16.psf.gz
-rw-r--r-- 1 root root 4,6K  2016-03-12 17:23
/etc/console-setup/cached_UTF-8_del.kmap.gz

But lately i found a file with *600* in there.

According to my own tests it is save to 'rm /etc/console-setup/*.gz' (obviously
keeping backups of those files somewhere is always a good habbit) and then to do a:

root ~ # command dpkg-reconfigure --priority=low --frontend=dialog console-setup

This will recreate those '/etc/console-setup/*.gz' files. After doing so over
here all was good again.



kind regards,

     Thilo

There is a slight possibility for the current console-setup to leave the
console unconfigured during the first boot. Have you observed
misconfigured console more than once?

Anton Zinoviev

Is this something reproducible?  Did you observe problems with console
configuration when there was a file with *600*?

It is safe to 'rm /etc/console-setup/cached_*'.  These files can be
recreated by 'setupcon --save-only'.

Anton Zinoviev

Anton Zinoviev schrieb/wrote:

Up to now this happend once. So i do not know how to reproduce this.
When it was 600 (one of those *.gz files) console did not catch up settings on
boot (font e.g.). After recreating it and then rebuild initramfs it was fine on
next reboot.

Thanks. I take a note about this.


kind regards,

     Thilo

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Nicolas LE CAM <niko.lecam@gmail.com>
To: Debian Bug Tracking System <818065@bugs.debian.org>
Subject: Re: console-setup is not read correctly at boottime and must be started
 manually
Bcc: Nicolas LE CAM <niko.lecam@gmail.com>

Package: console-setup
Version: 1.153
Followup-For: Bug #818065

Dear Maintainer,

Same problem here, I'm not sure if it's exactly the same cause though.

In my case it seems to be a problem with /tmp availability or writability so also related to bug #620491 except this one was happening with sysvinit and is marked fixed.

$ systemctl status console-setup.service
● console-setup.service - Set console font and keymap
   Loaded: loaded (/lib/systemd/system/console-setup.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2016-11-26 18:17:30 CET; 14min ago
  Process: 386 ExecStart=/lib/console-setup/console-setup.sh (code=exited, status=1/FAILURE)
 Main PID: 386 (code=exited, status=1/FAILURE)
      CPU: 393ms

nov. 26 18:17:30 rio systemd[1]: Starting Set console font and keymap...
nov. 26 18:17:30 rio console-setup.sh[386]: /bin/setupcon: 866: /bin/setupcon: cannot open /tmp/tmpkbd.LsV4Kk: No such file
nov. 26 18:17:30 rio systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
nov. 26 18:17:30 rio systemd[1]: Failed to start Set console font and keymap.
nov. 26 18:17:30 rio systemd[1]: console-setup.service: Unit entered failed state.
nov. 26 18:17:30 rio systemd[1]: console-setup.service: Failed with result 'exit-code'.

Executing /lib/console-setup/console-setup.sh in the console seems to fix the problem, no more errors reported afterwards :

$ systemctl status console-setup.service
● console-setup.service - Set console font and keymap
   Loaded: loaded (/lib/systemd/system/console-setup.service; enabled; vendor preset: enabled)
   Active: active (exited) since Sat 2016-11-26 18:32:54 CET; 14min ago
  Process: 340 ExecStart=/lib/console-setup/console-setup.sh (code=exited, status=0/SUCCESS)
 Main PID: 340 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 0B
      CPU: 0
   CGroup: /system.slice/console-setup.service

nov. 26 18:32:54 rio systemd[1]: Starting Set console font and keymap...
nov. 26 18:32:54 rio systemd[1]: Started Set console font and keymap.

regards,
Nicolas

Hello


I have just experienced this issue after "upgrading" (rebuilding) my live image to stretch from jessie.


As it is a live-image, every boot is "first boot" as Anton said could give issue.


So I looked a bit on the code, and I think the issue is caused by line 11 in console-setup (*), the line make so console-setup.sh does nothing at first run after boot, and as console-setup.service is only run once per boot, setupcon (which configure keyboard layout) is never run.


How did this ever get into testing? :)


* https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/init/console-setup.sh?id=85d541bcfe7557caee0e544ac6c547f97174db32#n11



Regards Kristian Klausen

Yes, in this case setupcon is never run from console-setup.sh.  However
there is no need to use setupcon in order to configure the font because
this is done by /lib/udev/rules.d/90-console-setup.rules and the
keyboard is configured by /lib/systemd/system/keyboard-setup.service.

How big is is this image?  Will it be possible to send it to me so I can
test?

Anton Zinoviev

Hello Anton
keyboard-setup.service doesn't seems to configure the layout, rerunning it change nothing but as soon I rerun console-setup.service the layout is fixed.
Around ~ 700MB, but I need to strip a few thing out before I can share it. I'm properly just gonna upload it to my webserver.

Regards Kristian Klausen

Hello,

I had the same issue.
Running a live-build image, nothing worked to setup the keyboard layout.

I found out that my image contained /etc/console-setup/cached_* files.
What really helped was adding a hook in live-build to remove those files, before the
image was built.

$ cat config/hooks/live/0900-cleanup.hook.chroot
#!/bin/sh
rm -f -- /etc/console-setup/cached_*


Cheers

Can you send the output of

ls --full-time /etc/console-setup/cached* /etc/default/console-setup /etc/default/keyboard

If the times of the cached files are more recent than the times of the
configuration files, then console-setup won't look at the configuration
files at all.

I don't know how live-config works but isn't the script
components/0150-keyboard-configuration (I am looking at the source
package of live-config) supposed to edit /etc/default/keyboard?  And if
this is so, then how it is possible for the cached files to be more
recent than /etc/default/keyboard?

Anton Zinoviev

/etc/default/ and did not set the keyboard parameters elsewhere.
Files in /etc/default/ aren't overwritten in the booted system (i.e.
looks same in booted system):
-rw-r--r-- root/root  4024 2017-03-17 06:50 squashfs-root/etc/console-setup/cached_UTF-8_del.kmap.gz
-rw-r--r-- root/root  4147 2017-03-17 06:50 squashfs-root/etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rwxr-xr-x root/root   471 2017-03-17 06:50 squashfs-root/etc/console-setup/cached_setup_font.sh
-rwxr-xr-x root/root   174 2017-03-17 06:50 squashfs-root/etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x root/root    73 2017-03-17 06:50 squashfs-root/etc/console-setup/cached_setup_terminal.sh
-rw-rw-r-- root/root   136 2017-03-14 09:47 squashfs-root/etc/default/console-setup
-rw-rw-r-- root/root   172 2017-03-12 17:39 squashfs-root/etc/default/keyboard


Same image, but this time I set on kernel command line:
locales=de_DE.UTF-8 keyboard-layouts=de keyboard-variants=nodeadkeys
The file date is newer, still keyboard layout not set.
-rw-rw-r-- 1 root root  136 2017-03-14 09:47:49.000000000 +0100 console-setup
-rw-rw-r-- 1 root root  172 2017-03-17 07:12:20.128082454 +0100 keyboard
-rwxr-xr-x 1 root root  471 2017-03-17 06:50:38.000000000 +0100 /etc/console-setup/cached_setup_font.sh
-rwxr-xr-x 1 root root  174 2017-03-17 06:50:38.000000000 +0100 /etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x 1 root root   73 2017-03-17 06:50:38.000000000 +0100 /etc/console-setup/cached_setup_terminal.sh
-rw-r--r-- 1 root root 4147 2017-03-17 06:50:38.000000000 +0100 /etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rw-r--r-- 1 root root 4024 2017-03-17 06:50:38.000000000 +0100 /etc/console-setup/cached_UTF-8_del.kmap.gz


I made a new image, without the hard coded keyboard + console-setup files.

Contents in squashfs:
"keyboard" has XKBLAYOUT="us", so not what I want.
-rwxr-xr-x 1 root root  471 2017-03-17 07:11:05.000000000 +0100 squashfs-root/etc/console-setup/cached_setup_font.sh
-rwxr-xr-x 1 root root  174 2017-03-17 07:11:05.000000000 +0100 squashfs-root/etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x 1 root root   73 2017-03-17 07:11:05.000000000 +0100 squashfs-root/etc/console-setup/cached_setup_terminal.sh
-rw-r--r-- 1 root root 4147 2017-03-17 07:11:04.000000000 +0100 squashfs-root/etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rw-r--r-- 1 root root 4024 2017-03-17 07:11:04.000000000 +0100 squashfs-root/etc/console-setup/cached_UTF-8_del.kmap.gz
-rw-r--r-- 1 root root  285 2017-03-17 07:11:04.000000000 +0100 squashfs-root/etc/default/console-setup
-rw-r--r-- 1 root root  150 2017-03-17 07:10:59.000000000 +0100 squashfs-root/etc/default/keyboard


After I boot (still same kernel command line parameters):
-rwxr-xr-x 1 root root  471 2017-03-17 07:11:05.000000000 +0100 /etc/console-setup/cached_setup_font.sh
-rwxr-xr-x 1 root root  174 2017-03-17 07:11:05.000000000 +0100 /etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x 1 root root   73 2017-03-17 07:11:05.000000000 +0100 /etc/console-setup/cached_setup_terminal.sh
-rw-r--r-- 1 root root 4147 2017-03-17 07:11:04.000000000 +0100 /etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rw-r--r-- 1 root root 4024 2017-03-17 07:11:04.000000000 +0100 /etc/console-setup/cached_UTF-8_del.kmap.gz
-rw-r--r-- 1 root root  285 2017-03-17 07:11:04.000000000 +0100 /etc/default/console-setup
-rw-r--r-- 1 root root  160 2017-03-17 07:18:22.112087333 +0100 /etc/default/keyboard


Here is an excerpt from /var/log/syslog:
Mar 17 07:18:24 localhost systemd[1]: Reached target Local File Systems.
Mar 17 07:18:24 localhost systemd[1]: Starting live-config contains the components that configure a live system during the boot process (late userspace)....
Mar 17 07:18:24 localhost systemd[1]: Starting Create Volatile Files and Directories...
Mar 17 07:18:24 localhost systemd[1]: Starting Raise network interfaces...
Mar 17 07:18:24 localhost systemd[1]: Starting Set console font and keymap...
Mar 17 07:18:24 localhost systemd[1]: Started Create Volatile Files and Directories.
Mar 17 07:18:24 localhost systemd[1]: Starting Update UTMP about System Boot/Shutdown...
Mar 17 07:18:24 localhost systemd[1]: Starting Network Time Synchronization...
Mar 17 07:18:24 localhost systemd[1]: Started Set console font and keymap.
Mar 17 07:18:24 localhost systemd[1]: Started Update UTMP about System Boot/Shutdown.
Mar 17 07:18:24 localhost systemd[1]: Started Network Time Synchronization.
Mar 17 07:18:24 localhost systemd[1]: Reached target System Time Synchronized.
Mar 17 07:18:24 localhost live-config[393]: live-config: debconf hostnameDevice "eth0" does not exist.
Mar 17 07:18:24 localhost live-config[393]: Device "eth0" does not exist.
Mar 17 07:18:24 localhost live-config[393]: Device "eth0" does not exist.
Mar 17 07:18:24 localhost systemd[1]: Reloading.
Mar 17 07:18:24 localhost systemd[1]: Reloading.
Mar 17 07:18:24 localhost systemd[1]: Started Raise network interfaces.
Mar 17 07:18:24 localhost systemd[1]: Reached target Network.
Mar 17 07:18:24 localhost live-config[393]:  user-setup sudo locales tzdata
Mar 17 07:18:24 localhost live-config[393]: Current default time zone: 'Europe/Berlin'
Mar 17 07:18:24 localhost live-config[393]: Local time is now:      Fri Mar 17 07:18:22 CET 2017.
Mar 17 07:18:24 localhost live-config[393]: Universal Time is now:  Fri Mar 17 06:18:22 UTC 2017.
Mar 17 07:18:24 localhost live-config[393]:  keyboard-configuration util-linux login openssh-server hooksls: cannot access '/lib/live/config-hooks/*': No such file or directory
Mar 17 07:18:24 localhost live-config[393]: .
Mar 17 07:18:24 localhost systemd[1]: Started live-config contains the components that configure a live system during the boot process (late userspace)..


It appears to me that "Set console font and keymap" is done before
live-config regenerates the files.

Funny thing is, I also tried to run "dpkg-reconfigure -f noninteractive
console-setup" from scripts (config hook or from an auto-login-script).
Didn't work either.

Cheers
Jörn

I think this explains the bug.

Anton Zinoviev

This happened to me as well, check if a slight change to the systemd
unit file helps:
/lib/systemd/system/console-setup.service
RequiresMountsFor=/usr /tmp

i.e. add /tmp
My /tmp is mounted as tmpfs so that could pose a problem. After changing
this line console-setup seems to start normally during the boot up.

On Sat, 26 Nov 2016 18:55:59 +0100 Nicolas LE CAM wrote:
 > Package: console-setup
 > Version: 1.153
 > Followup-For: Bug #818065
 >
 > Dear Maintainer,
 >
 > *** Reporter, please consider answering these questions, where
appropriate ***
 >
 > * What led up to the situation?
 > * What exactly did you do (or not do) that was effective (or
 > ineffective)?
 > * What was the outcome of this action?
 > * What outcome did you expect instead?
 >
 > *** End of the template - remove these template lines ***
 >
 > MIME-Version: 1.0
 > Content-Transfer-Encoding: 8bit
 > Content-Type: text/plain; charset="UTF-8"
 > From: Nicolas LE CAM
 > To: Debian Bug Tracking System <818065@bugs.debian.org>
 > Subject: Re: console-setup is not read correctly at boottime and must
be started
 > manually
 > Bcc: Nicolas LE CAM
 >
 > Package: console-setup
 > Version: 1.153
 > Followup-For: Bug #818065
 >
 > Dear Maintainer,
 >
 > Same problem here, I'm not sure if it's exactly the same cause though.
 >
 > In my case it seems to be a problem with /tmp availability or
writability so also related to bug #620491 except this one was happening
with sysvinit and is marked fixed.
 >
 > $ systemctl status console-setup.service
 > ● console-setup.service - Set console font and keymap
 > Loaded: loaded (/lib/systemd/system/console-setup.service; enabled;
vendor preset: enabled)
 > Active: failed (Result: exit-code) since Sat 2016-11-26 18:17:30 CET;
14min ago
 > Process: 386 ExecStart=/lib/console-setup/console-setup.sh
(code=exited, status=1/FAILURE)
 > Main PID: 386 (code=exited, status=1/FAILURE)
 > CPU: 393ms
 >
 > nov. 26 18:17:30 rio systemd[1]: Starting Set console font and keymap...
 > nov. 26 18:17:30 rio console-setup.sh[386]: /bin/setupcon: 866:
/bin/setupcon: cannot open /tmp/tmpkbd.LsV4Kk: No such file
 > nov. 26 18:17:30 rio systemd[1]: console-setup.service: Main process
exited, code=exited, status=1/FAILURE
 > nov. 26 18:17:30 rio systemd[1]: Failed to start Set console font and
keymap.
 > nov. 26 18:17:30 rio systemd[1]: console-setup.service: Unit entered
failed state.
 > nov. 26 18:17:30 rio systemd[1]: console-setup.service: Failed with
result 'exit-code'.
 >
 > Executing /lib/console-setup/console-setup.sh in the console seems to
fix the problem, no more errors reported afterwards :
 >
 > $ systemctl status console-setup.service
 > ● console-setup.service - Set console font and keymap
 > Loaded: loaded (/lib/systemd/system/console-setup.service; enabled;
vendor preset: enabled)
 > Active: active (exited) since Sat 2016-11-26 18:32:54 CET; 14min ago
 > Process: 340 ExecStart=/lib/console-setup/console-setup.sh
(code=exited, status=0/SUCCESS)
 > Main PID: 340 (code=exited, status=0/SUCCESS)
 > Tasks: 0 (limit: 4915)
 > Memory: 0B

Hi


I have this same problem and I tried this solution and it didn't fix the problem for me.  However, when I then ran 'rm /etc/console-setup/cached_*' and then 'setupcon --save-only' and this fixed the problem.



As I am running etckeeper, I checked to see the difference in the newly generated files and noticed that the old loadkeys in /etc/console-setup/cached_setup_keyboard.sh refers to a temporary file in /tmp whereas the new version refers to /etc/console-setup/cached_UTF-8_del.kmap.gz instead.  See here:



root@duck:/etc# git diff

diff --git a/console-setup/cached_setup_keyboard.sh b/console-setup/cached_setup_keyboard.sh

index bdc822d..30b46c1 100755

--- a/console-setup/cached_setup_keyboard.sh

+++ b/console-setup/cached_setup_keyboard.sh

@@ -10,4 +10,4 @@ kbd_mode '-u' < '/dev/tty3'

 kbd_mode '-u' < '/dev/tty4'

 kbd_mode '-u' < '/dev/tty5'

 kbd_mode '-u' < '/dev/tty6'

I suppose this fixes the problem with the upgrades of console-setup. But I
don't like this solution because even if it fixes the problem (does it?),
it is not the right solution.  I don't think console-setup
needs /tmp for its work.  This solution works only because requiring
/tmp to be mounted means some other dependency will be satisfied as
well.  But who knows what this other dependency is...

Anton Zinoviev

Hi Anton,

Just to be clear - I tried adding /tmp to the unit file and it did NOT fix the problem.  I had to re-generate the cache files to resolve the issue and I restored the system unit file to not require a mount for /tmp as before.

The bug is that there was a reference to a non-existent file in /tmp in the previous version of /etc/console-setup/cached_setup_keyboard.sh which disappeared when it was re-generated.  I imagine the /tmp file was there when it was originally generated, but it was of course not there on a subsequent reboot.  When I regenerated the cache files /etc/console-setup/cached_setup_keyboard.sh changed as follows:

Hi all,

I have this problem on 8 embedded systems running armbian stretch that all
reports error like this on the systemd journal:

Feb 16 14:17:10 rod-ba82a8 console-setup.sh[293]: /bin/setupcon: 866:
/bin/setupcon: cannot open /tmp/tmpkbd.BccRnI: No such file
Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Main process
exited, code=exited, status=1/FAILURE
Feb 16 14:17:10 rod-ba82a8 systemd[1]: Failed to start Set console font and
keymap.
Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Unit entered
failed state.
Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Failed with
result 'exit-code'

So it look like the /tmp mount is required. I added it into
the RequiresMountsFor line of the service file, run systemctl
daemon-reload, but this make no change on the boot: console-setup failed
with exactly the same error message.

Then I tryed to run 'setupcon' and 'reboot', no change.

Then I tryed to run 'systemctl start console-setup.service' and 'reboot':
it worked !.

So my conclusion so far are:

1) Yes setupcon and  console-setup.service require /tmp mount but this is
not the rot cause of the problem, even if the error message let you think
so.

2) Simply running 'systemctl start console-setup.service' manually solved
the problem on those 8 systems that also have /tmp added
into RequiresMountsFor.

Look like a timing and probably a dependency issue that make early
console-setup to fail because it didn't find a expected file into /tmp. I
don't know how this file is supposed to be there at bot time.

Best regards.
Jean-Christian

The console-setup service still fails on boot for the same reason:
- setupcon fails to access some /tmp file, even that the service runs
long after /tmp has been mounted and successfully used by other systemd
units.
- Even dpkg-reconfigure keyboard-configuration causes this bug since it
updates /etc/default/keyboard, which triggers the setupcon call, without
updating the cached scripts mentioned above.
- This is true on current Buster and Bullseye systems. On Stretch for
some reason, setupcon succeeds in these cases.

 Draga moja, volim tvoje komentare na objave na društvenim mrežama. Molim
vas, imam projekt koji želim podijeliti s vama.

Hallöchen!

I confirm this bug (at least, that the correct font is not set) on
Trixie on one of my two workstations.  It is difficult to say
whether the root cause is the same as for the issuer, as 10 years
are a long time.  On the other hand, the whole procedure doesn’t
seem to have changed:

- console-setup.service is started at boot time

- console-setup.service runs /lib/console-setup/console-setup.sh

- /lib/console-setup/console-setup.sh runs setupcon to recreate the
  /etc/console-setup/cache* files if:

  - run not at boot time OR
  - cache* files don’t exist or are outdated

- Finally: /lib/udev/rules.d/90-console-setup.rules runs
  /etc/console-setup/cached* at boot time (the exact trigger is
  unknown to me)

In my case, it is a race: udev runs cached_setup_font.sh too early in
the boot process.  Adding “sleep 2” at the top of
cached_setup_font.sh solves the problem.  So, at boot time happens
probably:

1. udev calls /etc/console-setup/cached*
2. The console is reset to default fonts
3. console-setup.service is started

On my workstation without this issue, (2) probably happens first.

My workaround is to patch /lib/console-setup/console-setup.sh so
that (3) *always* calls setupcon.

Bye,
Torsten.

Hey guys,

I think the last reason for ineffective console mode changes has been
fixed with this commit:
https://salsa.debian.org/installer-team/console-setup/-/commit/a7bea22

This is v1.228, hence live in Trixie.

That the tmpfiles cleanup removed the /tmp/tmpkbd.* files really is the
best plausible explanation for why console-setup.service > setupcon
fails to generate/update the /etc/console-setup/cached_* files, throwing
a "cannot open /tmp/tmpkbd.XXXXXX: No such file" error. That way, the
udev rules can never actually apply the intended console setup.

With this commit, the tmp files should remain, hence "setupcon --save"
from console-setup.service should not fail anymore, hence apply changes
to the console and update the cache on next boot after a config change.

Not sure about what Torsten says above: I am not aware of something else
which would reset/change the console font at boot, other than the udev
rules, and console-setup.service if the cache is missing or outdated?

Best regards,

Micha