The real question, however, Hans is: WHY do the tools care? And why do we care? There's innumerable situations where the clock couldn't become out of sync-- either forwards or backwards. Suppress the warnings and move on; is there any situation where those warnings are actually helpful or relevant beyond a "huh, my cmos battery died"? > On Jul 5, 2017, at 09:12, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > Hi, > >> On 05-07-17 11:30, Bastien Nocera wrote: >> ----- Original Message ----- >>> Hi, >>> >>>> On 04-07-17 16:41, Bastien Nocera wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >>>>> wrote: >>>>>> "Language and Keyboard Layout" >>>>>> >>>>>> I don't see how a normal (non live) non net-install differs >>>>>> from a net-install. In both cases anaconda is pretty much the >>>>>> only thing which is running and as such is the best place to >>>>>> ask about this. I agree that with livecds we need something >>>>>> else. >>>>> >>>>> It doesn't. Anaconda is the right place in both cases. But Workstation >>>>> has only the live image and netinstall images, so we don't consider >>>>> this case. >>>>> >>>>>> "Time and Date" >>>>>> >>>>>> It is important to get the timezone setup correctly *before* >>>>>> running the phase of anaconda where it formats filesystems >>>>>> and copies files. Otherwise various tools may complain about >>>>>> timestamps in the future for files created during install >>>>>> time when the timezone is later changed in such a way >>>>>> that the (timezone-adjusted) time becomes earlier. >>>>>> >>>>>> We've had several bugs related to this in the past and >>>>>> actually have moved timezone configuration up to an earlier >>>>>> point in the installer because of this. >>>> >>>> The timezone configuration is only needed for dual-boot installations where >>>> the BIOS is in local time instead of UTC, as I don't expect the installer >>>> to write anything but UTC dates on disk. >>> >>> The problem is with freshly generated files, if the timezone is say >>> CET, then those files (and also the filesystem creation timestamp in >>> the superblock) get created at UTC+1, if then after boot the user corrects >>> the timezone to say UTC-6 and within those 7 hours reboots the user >>> will get a bunch of complaints from fsck and other tools about timestamps >>> in the future. IIRC. esp. the fsck issue was nasty. >> Why is the superblock creation date in local time instead of UTC? > > 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. > > Regards, > > Hans > _______________________________________________ > desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
