On Wed, Jul 5, 2017 at 7:12 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
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.
OK so I just tested this with ext4, XFS and Btrfs in a VM. The VM date
is changed to 2018 before launching the installer.
XFS and Btrfs have no fsck, and they have no complaint about the
future dated superblock or file timestamps. Installed system boots
Ext4 has an fsck triggered during startup, it complains not about
superblock creation time, but rather last mount time which is stored
in the superblock, and fsck fixes this, the rw mount happens and
startup succeeds, no further errors.
Rolling back to the future dated superblock last mountime, and using
boot parameter fsck.repair=skip, the fsck is not run during startup,
file systems mount without complain, system starts up fine.
So near as I can tell there is no problem that requires setting the
timezone or even remotely correct date info in the installer.