Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10

[Alkis Georgopoulos]

This affects all Ubuntu CDs and installations after 14.10.

The VTs are not configured to show UTF-8 characters because of a wrong CHARMAP value at /etc/default/console-setup (ISO-8859-15 instead of UTF-8).

The cause most probably is that recent console-setup.postinst versions create a different configuration file based on LANG:

# rm /etc/default/console-setup
# LANG=C apt-get install --reinstall console-setup
# grep CHARMAP /etc/default/console-setup
CHARMAP="ISO-8859-15"

While with C.UTF-8 (or en_US.UTF-8 or whatever) it produces the correct CHARMAP:
# rm /etc/default/console-setup
# LANG=en_US.UTF-8 apt-get install --reinstall console-setup
# grep CHARMAP /etc/default/console-setup
CHARMAP="UTF-8"

I think this should be fixed in console-setup, but it's possible that the live CD code may want to use LANG=C.UTF-8 in any case.

[Alkis Georgopoulos (alkisg)]

> I think this should be fixed in console-setup, but it's possible that the live CD code may want to use LANG=C.UTF-8 in any case.

...I put livecd-rootfs in the affects list, please use LANG=en_US.UTF-8 instead of LANG=C and LC_ALL=C.

$ egrep -r 'LANG=|LC_ALL=' .
./debian/changelog: * Minor cleanups to BuildLiveCD (LANG=C, bump current suite)
./BuildLiveCD:LANG=C <===== this one
./live-build/auto/build:export LC_ALL=C <====== and this one
./live-build/ubuntu-touch/includes.chroot/etc/default/locale:LANG="en_US.UTF-8"
./live-build/ubuntu-touch/hooks/48-setup-env.chroot:LANG=en_US.UTF-8

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package console-setup - 1.108ubuntu7

---------------
console-setup (1.108ubuntu7) wily; urgency=medium

  * Fix incorrect versioning change from last upload; initramfs-tools
    0.85eubuntu12 looks wrong but was in fact correct.
  * If the locale is C during configuration, only set CHARMAP to ISO-8859-15
    on kFreeBSD; otherwise restore the previous behaviour from before the
    kFreeBSD port of using UTF-8 in that case (LP: #1484101).

 -- Colin Watson <email address hidden> Fri, 02 Oct 2015 11:18:04 +0100