Bug 184248 - anaconda uses different heuristics for determining timezones during installs and upgrades.
anaconda uses different heuristics for determining timezones during installs ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2006-03-07 13:07 EST by Ray Strode [halfline]
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-22 16:08:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ray Strode [halfline] 2006-03-07 13:07:34 EST
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 13:11:41 EST
"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 15:58:34 EST
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 16:07:55 EST
Moving to anaconda and changing summary...
Comment 4 Red Hat Bugzilla 2007-06-11 23:05:50 EDT
requested by Jams Antill
Comment 5 David Cantrell 2007-08-22 16:08:26 EDT
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.