Hi,
On 05-07-17 15:46, Eric Griffith wrote:
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"?
We care because various tools care. Why the tools care? That is a good
question, you could search for past bugs about this to make an
initial list of affected tools and start a discussion with the
maintainers of those tools.
Regards,
Hans
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
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
