----- Original Message ----- > 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 This is a problem that can be avoided in the installer itself. > > 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" By which point we've run the timezone selection in gnome-initial-setup. > 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 ? The installer should be as short as possible, with the majority of the configuration done at first boot because it makes the installation feel streamlined and faster and makes it easier to deploy OEM installations where no assumptions are made as to the target environment. _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
