Anaconda wishlist

[Máirín Duffy]

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 at redhat.com, 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