Red Hat Bugzilla – Bug 184248
anaconda uses different heuristics for determining timezones during installs and upgrades.
Last modified: 2007-11-30 17:11:26 EST
I did a fresh install of Fedora Core 4 today and then did an upgrade to the
When I logged in NetworkManager's applet complained that it couldn't find
required resources. Upon further debugging it looks like the hicolor icon cache
is out of date.
"Upon further debugging" means in this case running gtk-update-icon-cache -f
/usr/share/hicolor made the problem go away.
Okay, so this is actually rather a corner case. It will only happen to people
that do an FC4 install and then immediately upgrade to FC5. It's the result of
timezone wonkiness. The installer is assuming system time is UTC, I think, for
a fresh fc4 install, but uses the configured (locale specific) timezone for the
fc5 upgrade. The end result is that the timestamps on files are weird.
/root/install.log is something like 4 hours newer than /root/upgrade.log (even
though the fresh install happened before the upgrade).
gtk-update-icon-cache in the rpm %post scriplets for the packages during
upgrades are a no-op because the fc4 cache file has a newer timestamp than the
directory it's in.
It's hard to say exactly where the bug is really. Is it in the bios because
bioses don't hold timezone information? Is it in anaconda because it switches
heuristics for determining timezone depending on whether you do a fresh install
or an upgrade? Is it in gtk because gtk-update-icon-cache doesn't protect
itself against this kind of clock skew? Is it in NetworkManager because it's
%post script doesn't unconditionally recreate the cache (using -f to
gtk-update-icon-cache) even though it knows it wants to unconditionally recreate
the cache?. Hard to say.
One interesting note is that if any package in the entire upgrade package set
called gtk-update-icon-cache with -f in %post, then this problem wouldn't have
shown itself. The cache contents and timestamp would have been corrected.
Note gtk-update-icon-cache could perform some measures to protect against clock
skew by ensuring that the mtime of the icon dir is equal to the mtime of the
cache file. A similiar suggestion was given in
http://bugzilla.gnome.org/show_bug.cgi?id=314549 for gtk's rc files.
Moving to anaconda and changing summary...
requested by Jams Antill
This is an old corner case. We haven't done anything about it as of now and we
probably won't in the future, so we might as well be honest: CLOSED WONTFIX.