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. 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. -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
