Bug 184248 - anaconda uses different heuristics for determining timezones during installs and upgrades.
Summary: anaconda uses different heuristics for determining timezones during installs ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
 
Reported: 2006-03-07 18:07 UTC by Ray Strode [halfline]
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-22 20:08:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ray Strode [halfline] 2006-03-07 18:07:34 UTC
I did a fresh install of Fedora Core 4 today and then did an upgrade to the
latest rawhide.

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.

Comment 1 Ray Strode [halfline] 2006-03-07 18:11:41 UTC
"Upon further debugging" means in this case running gtk-update-icon-cache -f
/usr/share/hicolor made the problem go away.

Comment 2 Ray Strode [halfline] 2006-03-07 20:58:34 UTC
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.


Comment 3 Ray Strode [halfline] 2006-03-07 21:07:55 UTC
Moving to anaconda and changing summary...

Comment 4 Red Hat Bugzilla 2007-06-12 03:05:50 UTC
requested by Jams Antill

Comment 5 David Cantrell 2007-08-22 20:08:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.