On 05-07-17 11:30, Bastien Nocera wrote:
----- Original Message -----
> On 04-07-17 16:41, Bastien Nocera wrote:
>> ----- Original Message -----
>>> On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede <hdegoede(a)redhat.com>
>>>> "Language and Keyboard Layout"
>>>> I don't see how a normal (non live) non net-install differs
>>>> from a net-install. In both cases anaconda is pretty much the
>>>> only thing which is running and as such is the best place to
>>>> ask about this. I agree that with livecds we need something
>>> It doesn't. Anaconda is the right place in both cases. But Workstation
>>> has only the live image and netinstall images, so we don't consider
>>> this case.
>>>> "Time and Date"
>>>> It is important to get the timezone setup correctly *before*
>>>> running the phase of anaconda where it formats filesystems
>>>> and copies files. Otherwise various tools may complain about
>>>> timestamps in the future for files created during install
>>>> time when the timezone is later changed in such a way
>>>> that the (timezone-adjusted) time becomes earlier.
>>>> We've had several bugs related to this in the past and
>>>> actually have moved timezone configuration up to an earlier
>>>> point in the installer because of this.
>> The timezone configuration is only needed for dual-boot installations where
>> the BIOS is in local time instead of UTC, as I don't expect the installer
>> to write anything but UTC dates on disk.
> The problem is with freshly generated files, if the timezone is say
> CET, then those files (and also the filesystem creation timestamp in
> the superblock) get created at UTC+1, if then after boot the user corrects
> the timezone to say UTC-6 and within those 7 hours reboots the user
> will get a bunch of complaints from fsck and other tools about timestamps
> in the future. IIRC. esp. the fsck issue was nasty.
Why is the superblock creation date in local time instead of UTC?
It is in UTC, but if localtime is say 5:00 and the timezone is
UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone
to UTC + 1 and then reboots then the superblock timestamp translates
to 11:00 while localtime is still 5:xx and we get an error about
the timestamp being in the future.
> Really this is a solved problem for 8 years or so now, the
> has gone over this in much detail back then. We simply MUST ask for the
> timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.