Bug 219535 - The NetworkManager applet could not find some required resources. It cannot continue.
The NetworkManager applet could not find some required resources. It cannot c...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: NetworkManager (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-13 15:33 EST by Jon Masters
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-18 13:56:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages from londonpacket.boston.redhat.com (224.83 KB, text/plain)
2006-12-14 11:35 EST, Jon Masters
no flags Details
output from nm applet (5.33 KB, text/plain)
2006-12-14 14:03 EST, Jon Masters
no flags Details
install.log from londonpacket.boston.redhat.com (1.49 MB, text/plain)
2006-12-21 13:48 EST, Jon Masters
no flags Details
syslog for good measure (4.91 KB, text/plain)
2006-12-21 13:52 EST, Jon Masters
no flags Details
install.log from londonpacket.boston.redhat.com (40.47 KB, text/plain)
2006-12-29 01:02 EST, Jon Masters
no flags Details
syslog for good measure (3.78 KB, text/plain)
2006-12-29 01:03 EST, Jon Masters
no flags Details

  None (edit)
Description Jon Masters 2006-12-13 15:33:36 EST
Description of problem:

"The NetworkManager applet could not find some required resources. It cannot
continue". Same problem I was getting with new FC6 installs happens on a fresh
RHEL5 client install from today, immediately on first login.

Even though there might be a problem, does it need to shout?

Jon.
Comment 1 Jon Masters 2006-12-14 11:17:23 EST
This happens regardless of whether the NetworkManager service is running or not.

Jon.
Comment 2 Christopher Aillon 2006-12-14 11:27:37 EST
This sounds like a fudged install somehow.  Basically, it's missing some icons
which are provided by the NetworkManager-gnome package (which is the package
which is also generating the complaint).  Can you attach the syslog output?

Running `gtk-update-icon-cache /usr/share/icons/hicolor` ought to solve this on
your system, but this gets run in RPM %post many times on install (one by this
package and again by a lot of other desktop packages) so not quite sure where
the fudging is originating from.
Comment 3 Jon Masters 2006-12-14 11:34:11 EST
I ran gtk-update-icon-cache under sudo, it returned no error. NetworkManager's
notification applet is still popping up that dialog.

Jon.
Comment 4 Jon Masters 2006-12-14 11:35:18 EST
Created attachment 143656 [details]
/var/log/messages from londonpacket.boston.redhat.com
Comment 5 Christopher Aillon 2006-12-14 13:20:03 EST
Hm.  I suppose the syslog isn't as useful as I'd have hoped.  How about running
nm-applet from the command line?

Also, I just realized you need the -f flag to gtk-update-icon-cache to force the
regeneration of the icon cache (but do that after the command line so I can get
the output from that).
Comment 6 Jon Masters 2006-12-14 14:02:46 EST
Attached output before rebuilding icon cache. After rebuilding the gtk icon
cache, nm-applet correctly works. But note that this install was not "fudged" as
far as I aware - i.e. I'm sure something happened, but it appeard otherwise
succesful.

Jon.
Comment 7 Jon Masters 2006-12-14 14:03:22 EST
Created attachment 143677 [details]
output from nm applet
Comment 8 Christopher Aillon 2006-12-14 14:16:56 EST
So, that file exists in NetworkManager-gnome which calls g-u-i-c in its
postinstall script, which should take care of this.

% rpm -q --scripts NetworkManager-gnome 
postinstall scriptlet (using /bin/sh):
touch --no-create /usr/share/icons/hicolor
if [ -x /usr/bin/gtk-update-icon-cache ]; then
  gtk-update-icon-cache -q /usr/share/icons/hicolor
fi
postuninstall scriptlet (using /bin/sh):
touch --no-create /usr/share/icons/hicolor
if [ -x /usr/bin/gtk-update-icon-cache ]; then
  gtk-update-icon-cache -q /usr/share/icons/hicolor
fi
% rpm -qf =gtk-update-icon-cache
gtk2-2.10.4-8.el5
% rpm -q --scripts gtk2         
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig
/usr/bin/update-gdk-pixbuf-loaders i686-redhat-linux-gnu
/usr/bin/update-gtk-immodules i686-redhat-linux-gnu
postuninstall scriptlet (using /bin/sh):
/sbin/ldconfig


So the only way that NetworkManager-gnome's postinstall script would not get the
proper cache is if it were installed prior to gtk2.  Is it possible that
anaconda/RPM doesn't properly order these things?  Should gtk2 call
update-icon-cache in its %post?
Comment 9 Jeremy Katz 2006-12-14 15:07:50 EST
jcm -- can you attach /root/install.log?
Comment 10 Matthias Clasen 2006-12-14 15:49:14 EST
> Should gtk2 call update-icon-cache in its %post?

Sounds reasonable. If the install.log confirms that this is a package ordering
problem then we should do that.
Comment 11 Jon Masters 2006-12-14 15:59:03 EST
install.log from install attached, along with anaconda's related syslog. Do you
need anything else?

Jon.
Comment 15 Jon Masters 2006-12-21 13:48:12 EST
Created attachment 144204 [details]
install.log from londonpacket.boston.redhat.com
Comment 16 Jon Masters 2006-12-21 13:52:10 EST
Created attachment 144205 [details]
syslog for good measure
Comment 19 Jon Masters 2006-12-29 01:02:39 EST
Created attachment 144524 [details]
install.log from londonpacket.boston.redhat.com

This is the correct file. The previous one was from jcm.boston.redhat.com
instead.
Comment 20 Jon Masters 2006-12-29 01:03:57 EST
Created attachment 144525 [details]
syslog for good measure

Correct file this time.
Comment 22 Christopher Aillon 2007-01-02 15:31:27 EST
Matthias, shouldn't touching /usr/share/icons/hicolor be enough for
gtk-update-icon-cache to forcibly update the cache?  Or should I add -f?  I'm
rather stumped as to where the issue is if not here, but I'll try a fresh
install again to see if I can generate this scenario.
Comment 23 Matthias Clasen 2007-01-02 21:20:58 EST
If you touch /usr/share/icons/hicolor, that marks the icon cache as stale, so
a later gtk-update-icon-cache call will update it without using --force.

The NM-gnome %post does everything correctly, afaics. And there does not seem to
be a problem with that %post in the install log.
Comment 24 Christopher Aillon 2007-01-05 11:24:48 EST
Why does it not work unless it's in the cache anyway?  It seems like it ought to
fall back to loading it normally, otherwise...
Comment 25 Matthias Clasen 2007-01-05 18:14:03 EST
If the cache doesn't get marked as stale (by touching /usr/share/icons/hicolor),
it will mask any new icons that are added to the file system.
Comment 26 Christopher Aillon 2007-01-05 23:12:12 EST
Ah.  Well, clearly NM-gnome is doing that, so not sure what on earth is causing
this bug...
Comment 27 Jay Turner 2007-01-08 09:29:54 EST
Have anyone seen this with recent trees?
Comment 28 Jonathan Blandford 2007-01-18 13:56:20 EST
Looks like the ordering issue we're seeing.

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