Hi,
On 06-07-17 06:13, Chris Murphy wrote:
On Wed, Jul 5, 2017 at 7:12 AM, Hans de Goede <hdegoede@xxxxxxxxxx> 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
fine.
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.
Running a fsck after reboot is something users are going to file
bugs about:
https://bugzilla.redhat.com/show_bug.cgi?id=528284
Also various other writtenout files (config files) will have
timestamps in the future too and some tools will complain about that:
https://bugzilla.redhat.com/show_bug.cgi?id=59961
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.
That is simply not true, on ARM systems without an RTC having a
wrong date (of by a couple of years) is a big problem. Once the
date is of far enough (in either direction) SSL certificate
checks start to fail. And once that happens a lot of things break
including "dnf update"
A distro consists of many many moving pieces and quite a few of
those care about having a correct time / correct timestamps.
Given that we know that having a wrong system time at install
time is troublesome (e.g. running fsck on a big disk is not
nice) I'm wondering what are we trying to fix here ? What is
wrong with the installer showing a timezone selection screen ?
Regards,
Hans
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
