On 06/01/2015 09:25 AM, Matthew Miller wrote:
On Sun, May 31, 2015 at 01:56:41AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
The problem is that the installer has no idea if the system time is in
UTC or in the local timezone (let alone just wrong).
Right, but we were talking about the timezone selection spoke in the installer.
Getting the time wrong is an orthogonal issue.
Practically speaking, one of the common ways where the time ends up
wrong is when the system hwclock is set to the wrong timezone (or the
assumption about whether it is local time or utc is wrong).
some of the ways tz can be wrong at install time and cause later problems:
- filesystem creation timestamp
- timestamps relative to network resources (contact a repo on the
network mid or post install and the packages you suck down could have
timestamps in the future depending on which way you're off)
- config files that get written at install time
- various caches that get created at install time
we -really- wanted to pull tz selection out of anaconda when doing the
redesign (we couldn't pull it out of first boot because of the
OEM/third-party install case) but there were too many cases where it
would blow things up, sometimes rather catastrophically, and it is
extremely difficult to debug because the symptoms can be so bizarre and
unpredictable. in one case, a symptom was that the icons on the system
slowly started disappearing - that was because the timestamp on the icon
cache was in the future IIRC and whatever reads in the icons freaked out
when checking the age of the cache and getting a negative number.
sometimes it results in an unbootable system post-install. sometimes
random services fail bc of the timestamps on the config files
(exacerbated i think by subsequent updates that move new configs to .rpmnew)
i am really not an expert in all the technical details here, as i recall
jesse keating was the main person i consulted with when we were trying
to determine the feasibility of pulling tz selection from anaconda. i
think if the tz ends up being in UTC (and anaconda correctly detects
this which it does try to do, and the system isn't booted into another
OS that twiddles this back to non-UTC before the next boot) it still
doesn't help because the user would be changing the tz post-install in
g-i-s which is what would enable timestamps from the future.
it might be a good idea to bring this discussion to the actual installer
team (anaconda-devel-list@xxxxxxxxxx, not cc'ed as i see here) who are
the technical experts here and could give you a much more informed take
on pretty much all of the points brought up in the thread. a lot of
thought and planning went into the anaconda rewrite as i am sure all
appreciate here.
~m
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
