Bug#503189: tzsetup: Preseeding timezone doesn't work as described
>> d-i debian-installer/locale string en_US
>> d-i time/zone string Europe/Amsterdam
> What you are doing here is essentially invalid for interactive
> installations, and thus also for preseeded installations: you are
> selecting English as language and US as country, and then trying to set
> the time zone for NL, which is of course an invalid time zone for the
> US.
Makes sense.
> That will not work as it does not match what is documented for language
> and country preseeding [1]. You need d-i/locale=en_NL as Christian
> already explained. That will automatically give you the Dutch time zone
> (and you don't even need to preseed it at all!).
This is nice. But as Christian mentioned, there is no such locale as
"en_NL", which will probably keep users from specifying it. Maybe a note in
the D-I manual will help, that specifying non-existing locales doesn't
matter, as long as the two-letter codes are valid.
>> In a discussion on the debian-boot mailinglist, Christian Perrier
>> proposed[1] to try changing the locale from "en_US" to "en_NL". This
>> actually works! Unlike you would expect, but desired however, the
>> locale on the target system will be en_US.UTF-8.
>
> No, that's *exactly* what you'd expect.
I mean, if you specify "en_NL" as locale, an uninformed user would probably
be surprised to see LANG set to "en_US.UTF-8".
Just to check if I understand correctly; so "en_US" is the default locale
for an "en_<country>" setting that does not exist as real locale?
>> So, if this is the way we should preseed the timezone from now on, the
>> D-I manual must be changed to reflect this.
>
> No change needed as basically you should always have done it like this.
See my comment above in this post about adding a note to the D-I manual.
Would be nice that users get a bit more details.
> The fact that in the past an invalid timezone was accepted for the
> selected country could be seen as a bug.
Yep, understood.
> Also, in the case of tzsetup I think it is probably OK to allow a bit
> more freedom for preseeding than for interactive installs and allow to
> select any time zone.
>
> The attached patch should restore the old behavior. The patch also adds
> a sanity check that a (preseeded) value should be valid before the
> target system is actually modified.
Okay, great, seems reasonable.
Durk
Reply to: