default locales
As a preface, I'm using 3.2.14 on Ubuntu Server.
I've got FAI install clients that install packages (for example,
postgresql-8.3) that are dependent on the default locale being set to
(in my case) en_US.UTF-8. So, naturally I made sure that my
/srv/fai/config/debconf/CLASSNAME had the following:
locales locales/default_environment_locale select en_US.UTF-8
locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8
But I noticed that the clients didn't think that was the default locale;
SQL_ASCII encoding is a direct result of the default locale not being
set and falling back to 'C'. The evidence is pretty clear:
[EMAIL PROTECTED] chroot /target
host[~]# su - postgres -c "psql -l"
List of databases
Name | Owner | Encoding
--+---+---
postgres | postgres | SQL_ASCII
template0| postgres | SQL_ASCII
template1| postgres | SQL_ASCII
After some further investigation after ctrl+c'ing to hold off on the
reboot, I noticed that if I didn't include the 'language-pack-en'
package in my client's package list, a 'locale -a' shows only:
C
POSIX
and the system would spew messages like:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.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
But, FAI (task_debconf, in particular) really seemed to want to convince
me that everything was okay. There was nothing in the error.log, and
only this in the other logs:
# From fai.log
Calling task_debconf
Adding debconf data from /var/lib/fai/config/debconf/CLASSNAME
Reconfiguring package locales
# From debconf.log
info: Trying to set 'locales/default_environment_locale' [select] to
'en_US.UTF-8'
info: Loading answer for 'locales/default_environment_locale'
info: Trying to set 'locales/locales_to_be_generated' [multiselect] to
'en_US.UTF-8 UTF-8'
info: Loading answer for 'locales/locales_to_be_generated'
However, the results don't lie - the postgres-8.3 package thinks that
the locale is C (or at least was at the time postgres was installed).
So what gives? Well, I think (not 100% sure, but definitely pretty
suspicious) the reason is that minimal Ubuntu Server installs don't do
any localization, and only natively have the C and POSIX locales, which
is maybe only a nuisance in some cases, but obviously a big problem for
packages like postgresql. So, I suppose my only recourse here is to
configure the locales in a hook before the package installation. The
instsoft.CLASSNAME hook seems like it would be a good candidate, though
I haven't tested it yet (but will report back once I have).
But even if it does, I really think that FAI should check to make sure
the client really has the debconf information we're told we can set in
the $FAI_CONFIGDIR/debconf/ directory. Based on the log entries (or
lack thereof), I initially assumed nothing went wrong when setting up
the client's locales, which is not the case, and wasted time looking
elsewhere for problems.
Re: task_extrbase / debootstrap broken
Michael Tautschnig schrieb: I'm afraid that you need to investigate further, and it seems like nobody ever encountered that error before, so I don't see too many ways to help you. Suddenly I feel very special. ;) What I would do: Hack debootstrap (the main script) and add set -e -v -x to make it really really verbose. Add some explicit echo "retval: $?" at the end. And so forth... Will do that. But since it works somehow that's good enough until I got a working install procedure for SuSE Linux Enterprise Server. Will look again into this issue after that. tschüß thomas
Re: task_extrbase / debootstrap broken
Hi! [...] > > debootstrap completes with the following message: > "I: Base system installed successfully." > > but the return value is 141 not 0. task_error trips on this. > > I'm not sure who is to blame. Couldn't find any description what > returncode 141 is supposed to mean so far. > debootstrap at no point explicitly returns 141. This must thus be the result of some command run by debootstrap. The message "I: Base system installed successfully." is not really the last thing debootstrap does, so there is some leeway for further errors to pop up. I'm afraid that you need to investigate further, and it seems like nobody ever encountered that error before, so I don't see too many ways to help you. What I would do: Hack debootstrap (the main script) and add set -e -v -x to make it really really verbose. Add some explicit echo "retval: $?" at the end. And so forth... Sorry, Michael pgpSpRbwrtXqJ.pgp Description: PGP signature
Re: task_extrbase / debootstrap broken
> hiya > > Thomas Neumann schrieb: > > debootstrap completes with the following message: > > "I: Base system installed successfully." > > > > but the return value is 141 not 0. task_error trips on this. > > This patch makes Debian Etch and Debian Lenny debootstrapable again. > Didn't test with other distros or Debian Sid. (return value may change) > I think we should investigate this further before adding such a hack. An exit code of 141 really doesn't sound ok. Anybody volunteering? Best, Michael pgp8GonfXKM6k.pgp Description: PGP signature
Re: problem with secure apt
Hi! On Thu, Nov 06, 2008 at 12:08:34AM +0100, Michael Tautschnig wrote: > The following should do the trick, which is only in effect during installs > (and > not softupdates): > > Create /etc/apt/apt.conf.d/10fai containing > > APT::Get::AllowUnauthenticated "true"; > Aptitude::CmdLine::Ignore-Trust-Violations yes; > > which is actually just what FAI_ALLOW_UNSIGNED results in during installs. Thanks, that did the trick ... Greetings Henrik signature.asc Description: Digital signature
Re: task_extrbase / debootstrap broken
hiya Thomas Neumann schrieb: > debootstrap completes with the following message: > "I: Base system installed successfully." > > but the return value is 141 not 0. task_error trips on this. This patch makes Debian Etch and Debian Lenny debootstrapable again. Didn't test with other distros or Debian Sid. (return value may change) tschüß thomas --- original/subroutines-linux 2008-10-28 10:40:08.0 +0100 +++ patched/subroutines-linux 2008-11-12 10:36:06.0 +0100 @@ -168,7 +168,14 @@ echo "No base.tgz found. Calling debootstrap." [ -z "$FAI_DEBOOTSTRAP" ] && die "$FAI_DEBOOTSTRAP undefined. Aborting" call_debootstrap $FAI_DEBOOTSTRAP - task_error 801 $? +RETVAL=$? +echo "debootstrap return value: $RETVAL" +# debootstrap completes with the following message: +# "I: Base system installed successfully." but the return code is 141 +if [ $RETVAL = 141 ] ; then + RETVAL=0 +fi +task_error 801 $RETVAL fi fi # now we can copy fstab
