Hello all. Adding some information below...
On Sat, Jan 30, 2016 at 08:42:27PM +0100, Michael Biebl wrote: > Am 30.01.2016 um 20:41 schrieb Michael Biebl: > > Control: tags -1 moreinfo > > > > On Mon, 17 Nov 2014 23:30:24 +0000 Philipp Hug <deb...@hug.cx> wrote: > >> Hi Philippe, > >> > >> By looking at the code it seems that systemd sets > >> /sys/module/vt/parameters/default_utf8 > >> based on the locale setting which makes sense: > >> > >> https://github.com/systemd/systemd/blob/master/src/vconsole/vconsole-setup.c#L92 > > > > > > Well, we don't use systemd-vconsole in Debian. > > So it's still unclear to me, which part of the system is supposed care > > for vt.default_utf8=0. > > If it's a kernel parameter, as Philippe says, why should systemd care > > for it? > > > > Philippe, could you also please elaborate what this kernel parameter is > supposed to do. Is there documentation somewhere? I've recently been looking into related things so I'll add some information here in hope that it can be useful. First, the vt.default_utf8 kernel parameter is documented in https://www.kernel.org/doc/Documentation/kernel-parameters.txt cited for your convenience: vt.default_utf8= [VT] Format=<0|1> Set system-wide default UTF-8 mode for all tty's. Default is 1, i.e. UTF-8 mode is enabled for all newly opened terminals. This parameter is a module parameter for the vt module and configuration of the terminal is set up according to the parameter by the kernel module itself, see: http://sources.debian.net/src/linux/4.3.3-5/drivers/tty/vt/vt.c/?hl=165#L165 Now lets put this in a Debian context. The vt.default_utf8 is pretty much disregarded completely! As already mentioned systemd-vconsole-setup is not (currently) used in Debian and this is AFAIK the only program that takes vt.default_utf8 into consideration. In Debian we instead have (had) two different ways of configuring the console, either via the (in stretch/sid) no longer shipped /etc/init.d/kbd init script (configured via /etc/kbd/config) or via console-setup (which has it's own configuration)... (Please note that the kbd init script is *not* removed on package upgrade if there's been any active configuration made by the system administrator, so /can/ still be around on upgraded systems.) The kbd init script always configures the terminal to use or not the utf8 mode based on what it's own configuration says. # determine the system charmap ENV_FILE='' [ -r /etc/environment ] && ENV_FILE="/etc/environment" [ -r /etc/default/locale ] && ENV_FILE="/etc/default/locale" [ "$ENV_FILE" ] && CHARMAP=$(set -a && . "$ENV_FILE" && locale charmap) if [ "$CHARMAP" = "UTF-8" -a -z "$CONSOLE_MAP" ] then UNICODE_MODE=yes fi The usage of the entire init script is conditional on console-setup not being installed, and guessing from popcon data it's likely that anyone who uses kbd also uses console-setup in the very much dominating normal case. This pretty much leaves console-setup as the only relevant case to consider in general (ignoring special-cases mentioned above). AFAIK console-setup also completely disregards vt.default_utf8 kernel setting and always explicitly configures the terminal to use or not utf8 mode based on locale. I'm not sure what the usecase of having your locale set to use UTF-8 while avoiding to set up the console in the same mode is. I thus think console-setup pretty much behaves as expected. The kernel parameter is not an *override* after all, it's a default (fallback)! If you don't want console-setup to configure your consoles, then the right solution is to uninstall it! (Yes, that's practically doable.) Putting this all back into the context of the original bug report I'm not sure exactly whats going on. If this for example was a symptom of #759657 then the console should have been left in the vt.default_utf8 state and not the other way around. The original reporter says he needs to actively rerun the locale setup to end up correct. That's likely the cause. Something is actively setting up the locale in utf8 mode and configuring the console to match. Track that problem down and you'll likely also find/fix the cause for the console being configured. Either way, this is definitely not caused by systemd-vconsole-setup! HTH. Regards, Andreas Henriksson