Anaconda wishlist

[Bastien Nocera]

----- Original Message -----
> 
> 
> 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.

>From what I can understand from this, the problem isn't actually the timezone
(because if whether I'm in New York or Timbuktu, the UTC time written to disk
will still be the same). What you need is the right time. Which we could make
sure to pull from the network if it's available.

And if we're not connected to the network, there's nothing extra to install and
modify on the disk, we're just copying whatever's on the read-only image we're
trying to install.

So, in effect, the timezone (and UTC mode switch) would only need to be available
when installing data from the network, but network time isn't available.

> 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
> --
> desktop mailing list
> desktop at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/desktop