The real question, however, Hans is: WHY do the tools care? And why do we care?
There's innumerable situations where the clock couldn't become out of sync--
either forwards or backwards. Suppress the warnings and move on; is there any situation
where those warnings are actually helpful or relevant beyond a "huh, my cmos battery
died"?
> On Jul 5, 2017, at 09:12, Hans de Goede <hdegoede(a)redhat.com> wrote:
>
> Hi,
>
>> On 05-07-17 11:30, Bastien Nocera wrote:
>> ----- Original Message -----
>>> Hi,
>>>
>>>> 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>
>>>>> wrote:
>>>>>> "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
>>>>>> else.
>>>>>
>>>>> 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 anaconda team
>>> 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.
>
> Regards,
>
> Hans
> _______________________________________________
> desktop mailing list -- desktop(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org