On Thu, Jul 06, 2017 at 10:56:18AM +0200, Hans de Goede wrote: > 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 In that bug report, fsck *fails*. From what Chris writes and from what I remember, this was fixed a while back, and now it'll just give a quick warning. That's not really comparable, it's unlikely that users will care. > 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 In that bug report the user had the RTC in local time. That just doesn't work ;) (And timestamps will be wrong only if a) RTC is in local time, b) the RTC is used with a different time zone that it was set with, c) there is no network connection so the system time is not fixed on the way.) > >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 ? I don't have an opinion when (and if) to ask about the timezone, but it seems that people are attributing all possible problems to the wrong timezone, when in fact it should have little effect. In particular it should not have an effect on timestamps, unless you try to configure the computer with RTC in local time, which systemd warns about and which is broken. Zbyszek _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
