*** Please type your report below this line *** I am trying to use debconf to preseed the values for the locales package in Debian squeeze, so that I can reconfigure it non-interactively to, e.g., generate all locales. I am experiencing the same symptoms described in bug #592216; however, it works for other packages, e.g. sun-java6-bin: I am able to set the values with debconf-set-selections, but if I reconfigure locales with dpkg-reconfigure (or reinstall it with, e.g., apt-get install --reinstall locales, for that matter), debconf values are reset and the new locales are not generated. Bug #592216 is officially resolved in version 2.9-13 of the package. Squeeze has 2.11.3-4, so I expected the bug to be fixed, but it doesn't seem to be the case. Possibly related open bugs: #685957 (locales: dpkg-reconfigure defaults to "None" instead of locale selected in installer) #696725 (locales not generated after upgrade)
Hello, my tests confirm that bug 592216 is still valid at wheezy. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592216 At noninteractive debconf frontend. Regards. Andre Felipe Machado http://www.techforce.com.br
Hello, My tests confirmed that /etc/locale.gen settings prevents debconf locales preseeding using noninteractive frontend for dpkg-reconfigure. https://lists.debian.org/debian-user/2007/10/msg00480.html Regards. Andre Felipe Machado http://www.techforce.com.br
I have re-run the exact commands listed in bug#592216, and I have been unable to reproduce the original problem. If you are able to, please give us a way to reproduce it.
Hello, Aurelien Maybe, because, using puppet, I was trying to reconfigure a pre-existent Debian 7.4 VM template, that had an /etc/default/locale already configured. And only using noninteractive frontend for debconf. I followed the instructions of http://www.debian.org/releases/stable/amd64/apbs03.html.en and edited the resulting file to only include the locale settings. If one executes debconf with other frontends, it honors the user choices. The VM template was a basic install, with custom partitioning. Removing /etc/default/locale caused the debconf noninteractive to work as expected. Is this behaviour a design choice? Maybe an alert and or documentation. I will try again with a completely local fresh vm install (the other is a corporative one...) to record my exact steps. Regards. Andre Felipe On 08/Apr/2014 17:37 Aurelien Jarno <aurelien@aurel32.net> wrote ..
Hello, Aurelien
I made a fresh net-install of Debian 7.4 on a virtualbox VM, configuring for
only en_US.UTF-8.
After finishing installation, verified the /etc/default/locale.gen containing
only the en_US.UTF-8 entry.
Created the /var/cache/debconf/locale.seed file with the previously captured
content as described at previous email.
root@debianlocale:/var/cache/debconf# /usr/bin/debconf-set-selections
/var/cache/debconf/locale.seed; /usr/sbin/dpkg-reconfigure
--frontend=noninteractive locales
Generating locales (this might take a while)...
en_US.UTF-8... done
Generation complete.
Then moved away the /etc/default/locale.gen
root@debianlocale:/var/cache/debconf# /bin/mv /etc/locale.gen /tmp/ ;
/usr/bin/debconf-set-selections /var/cache/debconf/locale.seed;
/usr/sbin/dpkg-reconfigure --frontend=noninteractive locales
Generating locales (this might take a while)...
en_US.ISO-8859-1... done
en_US.ISO-8859-15... done
en_US.UTF-8... done
pt_BR.ISO-8859-1... done
pt_BR.UTF-8... done
Generation complete.
*** update-locale: Warning: LANGUAGE ("en_US:en") is not compatible with LANG
(pt_BR.UTF-8). Disabling it.
root@debianlocale:/var/cache/debconf#
Regards.
Andre Felipe
Hi, Thanks for the test. This is normal, the configuration file have higher priority than debconf. After removing the configuration file, the debconf values are taken into account as expected. Here the new debconf value is not taken into account because there is already a value in /etc/default/locale. For me everything works as expected, that is the values are taken from debconf only if there are not already defined in the configuration file. Aurelien
Hello, I understand the reasoning, but the behaviour does not seem consistent / coherent with expected behaviour of using preseed for clean installs. One expects preseed way to honor the preseed file, as the system is a fresh install for automated deployment. If applied over a manually installed, carefully configured system, this behaviour is logic. But for a automated deployment using preseed, I guess not. When one fires an automated deployment using preseed, it is expected to honor preseed file choices. Is there a good way to detect the different procedures of installation? Maybe using a predefined comment on the file registering the previously applied procedure. Regards. Andre Felipe Machado
The reasoning is that the locales package is already installed and configured. It is therefore not a fresh install from the locales package point of view. If you use set the preseed values *before* the locales packages is installed, thus within debian-installer, this value will be honored. Alternatively I *think* that using debian-installer with the C "locale" will not install the locales package and thus that the preseeded values will be used later when the package is installed. If we change the behavior to trust the debconf value instead of the configuration file, users will complain that the changes in the configuration file are lost. The debconf-devel(7) manual is clear that debconf should not be used as a registery (there is even a lintian tag [1] for that), and that the configuration file should be read before running debconf and written after. Aurelien [1] http://lintian.debian.org/tags/debconf-is-not-a-registry.html
Dear maintainers,
I badly got bitten by this bug, too, while trying to (automatically)
install Debian Jessie (stable) with FAI.
When installing locales and then reconfiguring it with
# dpkg-reconfigure locales
it works as expected using dialog input method.
Trying to reconfigure locales noninteractively, it fails:
# echo "set locales/locales_to_be_generated de_DE.UTF-8 UTF-8" | chroot
$NFSROOT debconf-communicate
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or
directory
locale: Cannot set LC_ALL to default locale: No such file or directory
0 value set
# echo "set locales/default_environment_locale de_DE.UTF-8" | chroot
$NFSROOT debconf-communicate
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or
directory
locale: Cannot set LC_ALL to default locale: No such file or directory
0 value set
# chroot $NFSROOT dpkg-reconfigure -fnoninteractive locales
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or
directory
Workaround (thanks to Thomas Lange from FAI):
Don't install locales with all the other packages but seperately (e. g.
with a script). Configure locales before installation. Do not
reconfigure them (noninteractively).
https://lists.uni-koeln.de/pipermail/linux-fai/2015-May/thread.html#10890
https://lists.uni-koeln.de/pipermail/linux-fai/2015-May/010922.html
Thanks for attention.
Christian