Bug#766228: systemd does not care /etc/default/grub

[Andreas Henriksson]

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 <debian at 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