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.
This happens regardless of whether the NetworkManager service is running or not. Jon.
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.
I ran gtk-update-icon-cache under sudo, it returned no error. NetworkManager's notification applet is still popping up that dialog. Jon.
Created attachment 143656 [details] /var/log/messages from londonpacket.boston.redhat.com
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).
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.
Created attachment 143677 [details] output from nm applet
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?
jcm -- can you attach /root/install.log?
> 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.
install.log from install attached, along with anaconda's related syslog. Do you need anything else? Jon.
Created attachment 144204 [details] install.log from londonpacket.boston.redhat.com
Created attachment 144205 [details] syslog for good measure
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.
Created attachment 144525 [details] syslog for good measure Correct file this time.
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.
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.
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...
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.
Ah. Well, clearly NM-gnome is doing that, so not sure what on earth is causing this bug...
Have anyone seen this with recent trees?
Looks like the ordering issue we're seeing.