This is a weird bug I just experienced today after applying package updates that had been pending since February 6th. GNOME shell would not start, I was greeted with the fail whale instead of the GDM greeter, and when using startx under my user account.
The log (see attached file) contained this:
failed to create drawable
(gnome-shell:1855): St-WARNING **: Failed to load /usr/share/gnome-shell/theme/noise-texture.png: Unrecognized image format (approx. translation)
(gnome-shell:1855): St-CRITICAL **: _st_create_texture_material: assertion `src_texture != COGL_INVALID_HANDLE' failed
So I downgraded everything that could be related to graphics (Xorg, mutter, libdrm, cairo, pixman), with no luck. I then downgraded more packages chosen sometimes at random, and eventually succeeded. The batch of "yum downgrade" that fixed the bug was this one:
Feb 18 10:54:08 Installed: gvfs-1.14.2-2.fc18.x86_64
Feb 18 10:54:10 Installed: pulseaudio-libs-2.1-5.fc18.x86_64
Feb 18 10:54:12 Installed: pulseaudio-2.1-5.fc18.x86_64
Feb 18 10:54:13 Installed: fftw-libs-long-3.3.3-4.fc18.x86_64
Feb 18 10:54:14 Installed: fftw-libs-double-3.3.3-4.fc18.x86_64
Feb 18 10:54:14 Installed: fftw-libs-single-3.3.3-4.fc18.x86_64
Feb 18 10:54:15 Installed: fftw-libs-quad-3.3.3-4.fc18.x86_64
Feb 18 10:54:16 Installed: pulseaudio-utils-2.1-5.fc18.x86_64
Feb 18 10:54:19 Installed: xulrunner-17.0.1-1.fc18.x86_64
Feb 18 10:54:24 Installed: firefox-17.0.1-1.fc18.x86_64
Feb 18 10:54:24 Installed: pulseaudio-module-x11-2.1-5.fc18.x86_64
Feb 18 10:54:25 Installed: fftw-libs-3.3.3-4.fc18.x86_64
Feb 18 10:54:25 Installed: fftw-3.3.3-4.fc18.x86_64
Feb 18 10:54:26 Installed: pulseaudio-module-bluetooth-2.1-5.fc18.x86_64
Feb 18 10:54:27 Installed: pulseaudio-module-gconf-2.1-5.fc18.x86_64
Feb 18 10:54:27 Installed: pulseaudio-libs-glib2-2.1-5.fc18.x86_64
Feb 18 10:54:29 Installed: gvfs-afp-1.14.2-2.fc18.x86_64
Feb 18 10:54:29 Installed: gvfs-obexftp-1.14.2-2.fc18.x86_64
Feb 18 10:54:30 Installed: gvfs-archive-1.14.2-2.fc18.x86_64
Feb 18 10:54:30 Installed: gvfs-smb-1.14.2-2.fc18.x86_64
Feb 18 10:54:31 Installed: gvfs-fuse-1.14.2-2.fc18.x86_64
Feb 18 10:54:32 Installed: gvfs-afc-1.14.2-2.fc18.x86_64
Feb 18 10:54:32 Installed: gvfs-gphoto2-1.14.2-2.fc18.x86_64
Feb 18 10:54:33 Installed: harfbuzz-0.9.7-1.fc18.x86_64
Feb 18 10:54:34 Installed: dyninst-8.0-1.fc18.x86_64
Feb 18 10:54:37 Installed: gcr-3.6.2-2.fc18.x86_64
Feb 18 10:54:39 Installed: colord-0.1.28-1.fc18.x86_64
Feb 18 10:54:41 Installed: gnome-abrt-0.2.4-1.fc18.x86_64
Feb 18 10:54:42 Installed: shared-mime-info-1.0-7.fc18.x86_64
Feb 18 10:54:44 Installed: ltrace-0.7.2-1.fc18.x86_64
Feb 18 10:54:44 Installed: libipa_hbac-1.9.4-3.fc18.x86_64
Feb 18 10:54:45 Installed: pulseaudio-gdm-hooks-2.1-5.fc18.x86_64
Feb 18 10:54:45 Installed: pulseaudio-libs-2.1-5.fc18.i686
Feb 18 10:54:46 Installed: harfbuzz-0.9.7-1.fc18.i686
The funny thing is, upgrading these packages again did not reintroduce the bug, so I'm sorry to say I cannot reproduce the problem. But still, it might be worth a look given it makes the system completely unusable.
Created attachment 698824 [details]
This is causing yum update to fail on MATE as well due to the package being unsigned. Please fix this ASAP.
(In reply to comment #0)
> This is a weird bug I just experienced today after applying package updates
> that had been pending since February 6th. GNOME shell would not start, I was
> greeted with the fail whale instead of the GDM greeter, and when using
> startx under my user account.
> The log (see attached file) contained this:
> failed to create drawable
> (gnome-shell:1855): St-WARNING **: Failed to load
> /usr/share/gnome-shell/theme/noise-texture.png: Unrecognized image format
> (approx. translation)
> (gnome-shell:1855): St-CRITICAL **: _st_create_texture_material: assertion
> `src_texture != COGL_INVALID_HANDLE' failed
This looks like gdk-pixbuf's cache being broken.
> The funny thing is, upgrading these packages again did not reintroduce the
> bug, so I'm sorry to say I cannot reproduce the problem. But still, it might
> be worth a look given it makes the system completely unusable.
And yeah, if some package reran the gdk-pixbuf-query-loaders, it would start working again.
(In reply to comment #2)
> This is causing yum update to fail on MATE as well due to the package being
> unsigned. Please fix this ASAP.
Either you're commenting in the wrong bug, or you're very confused.
Colin, this indeed looks like a plausible theory. So:
1) Any idea where the corruption can come from (upgrade went fine, no power outage or problems like that)?
2) Is that sensibility to gdk-pixbuf loaders bug specific to the Shell?
3) What can be done so that such a small bug can break the whole desktop?
(In reply to comment #4)
> Hi Dan,
> (In reply to comment #2)
> > This is causing yum update to fail on MATE as well due to the package being
> > unsigned. Please fix this ASAP.
> Either you're commenting in the wrong bug, or you're very confused.
Probably. Is there a link in upstream gnome bugzilla to use for tracking on this? Is this a confirmed bug upstream? Is there a plan to fix this for Fedora 19 upgrades?
FWIW, on my last 'yum update', Shell crashed shortly after, respawned itself, and ran fine thereafter. I didn't see any kind of 'system non-functional' stuff.
Milan: can you tell from your yum history what packages were included in the initial update that broke this? I think we need to track down what update could be busting the pixbuf cache, and see if it's a general issue or something flukey that just hit you.
Dan, there's zero point proposing this as blocking F*18* beta :)
if it's a general issue for f18->f19 upgrades it could possibly block F19, but let's get that straight first.
Created attachment 745359 [details]
Upgraded packages that broke the Shell
Adam: attached is the excerpt of /var/log/yum.log corresponding to the "yum upgrade" call that broke the Shell. The problem is, this was a very large upgrade (one of the reasons I do not apply upgrades very often is precisely that I cannot afford frequent breaks... :-). If you exclude texlive, there are about 300 updated packages.
Created attachment 745370 [details]
Downgraded packages that did not fix the Shell crash
And here is the list of packages I downgraded without fixing the problem, in case it may be useful.
Created attachment 745373 [details]
Downgraded packages that fixed the Shell crash
...and, for completeness, the ones that fixed the problem, as given in the description above. As Colin suggested, this downgrade probably just triggered a cache rebuild, so these packages may not be directly related to the crash.
I had just logged as root using Ctrl+Alt+F2 and ran ">yum update". The rest of the packages were updated and for some reason the problem with the Gnome login screen disappeared. Yum update did not work in my personal account.
I think the problem occurred during the updating procedure using the Software Manager, which I think is a very bad task. You cannot mark/unmark all the packages... And if you update several packages simultaneously the task break without any warning...
Thank you, Milan.
I would just like to add that I had the same problem with gdm + gnome-shell being without icons and gnome-shell pretty much oopsing immediately on login.
This was indeed fixed by running sudo gdk-pixbuf-query-loaders --update-cache, as Colin suggested (thanks!).
In my case the cache corruption was likely caused by the kernel locking up in the middle of a dist-upgrade (sic).
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.