Red Hat Bugzilla – Bug 723160
Gnome-shell presents enormous warning dialog
Last modified: 2011-08-08 04:06:40 EDT
Created attachment 513740 [details]
screen after boot with enormous dialog
Description of problem:
I booted Fedora-16-Nightly-20110718.08-x86_64-Live-desktop.iso in virt-manager (KVM).
After startup gnome-shell presents a standard warning dialog saying "Gnome 3 failed to load" (or something similar). But it creates the dialog ENORMOUS, I see only two letters on my whole screen. See attached screenshot.
I need to have at least 2GB of RAM in my virtual machine, because the Xorg itself takes 1.3GB just to display it.
It is possible to close the dialog with Enter. Xorg then restart into GDM. The login is no longer possible, you just see error message "Gnome 3 encountered some problems." (or similar) and button "Log out".
In /var/log/messages there are some segfaults reported:
Jul 19 04:16:15 localhost kernel: [ 57.441872] gsettings-data-: segfault at 18 ip 00007f4e19811951 sp 00007fff07d72c70 error 4 in libgconf-2.so.4.1.5[7f4e197f8000+2f000]
Jul 19 04:16:16 localhost kernel: [ 57.944582] gsettings-data-: segfault at 18 ip 00007fefb5ba3951 sp 00007fff8fb95200 error 4 in libgconf-2.so.4.1.5[7fefb5b8a000+2f000]
Jul 19 04:16:26 localhost kernel: [ 68.727503] gnome-settings-: segfault at 1 ip 00007fd4dabbc071 sp 00007fffc8a3e6c0 error 4 in libc-2.14.90.so[7fd4dab73000+19e000]
Jul 19 04:16:39 localhost kernel: [ 81.610993] gnome-settings-: segfault at 1 ip 00007f22b7eec071 sp 00007fff4629d080 error 4 in libc-2.14.90.so[7f22b7ea3000+19e000]
Jul 19 04:17:40 localhost kernel: [ 142.319385] at-spi-registry: segfault at 18 ip 00007f4c307e7951 sp 00007fffdf4d10f0 error 4 in libgconf-2.so.4.1.5[7f4c307ce000+2f000]
I also see kernel deadlock errors and selinux errors.
I tried to boot with selinux=0, didn't help. I tried different video driver in KVM (wmvga instead of cirrus), didn't help.
What information can I provide to help solving this problem?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot the ISO in virt-manager.
This is probably F16Beta blocker because of criterion #14:
"The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)"
Created attachment 513741 [details]
Created attachment 513742 [details]
After discussion with adamw marking also as F16Alpha-NTH.
Created attachment 514732 [details]
After a fresh rawhide install this morning, and logging into GNOME, I see the the typical "GNOME3 failed to load" dialog. It appears to be sized correctly, perhaps something changed to fix this problem?
Discussed at the 2011-07-22 alpha blocker bug review meeting. More information is needed before making a decision on this bug.
The impact of this issue is unclear. How many users are hitting this? What types of install bring out this behavior? Does it happen on bare metal installs?
I performed additional testing.
1. This concerns booting livecd, not booting a freshly installed system. That might be different.
2. I re-tested with Fedora-16-Nightly-20110722.09-x86_64-Live-desktop.iso (and i686). The same issue is still present. (Note: It is necessary to disable selinux to boot at all).
3. I tested on two bare metal machines. Both presented the same issue, so it clearly happens also on bare metal (I'm changing blocker bug to F16Alpha). You have to force failsafe mode to trigger this behavior. I did that by booting using "safe video" option.
Created attachment 514988 [details]
bug demonstration video
can we isolate whether this is down to the fallback mode per se, or vesa? you can test with fallback mode using a native driver by booting to gnome shell once, going to control center, System Info, checking the box to force fallback mode at the next login, then logging out and logging back in. if you do that on one of the same systems you tested with vesa, that should let us know whether it's vesa or fallback that's the issue.
Fedora Bugzappers volunteer triage team
oh, if this is happening in fallback mode, it's clearly not the shell that's at fault. this may wind up being a graphics driver issue, but for now moving to gnome-session.
Fedora Bugzappers volunteer triage team
(In reply to comment #8)
> can we isolate whether this is down to the fallback mode per se, or vesa? you
> can test with fallback mode using a native driver by booting to gnome shell
> once, going to control center, System Info, checking the box to force fallback
> mode at the next login, then logging out and logging back in. if you do that on
> one of the same systems you tested with vesa, that should let us know whether
> it's vesa or fallback that's the issue.
Unfortunately the error dialog is not displayed if you force the fallback mode manually, I just tried that. I don't know how to trigger displaying that dialog in another way than using vesa driver.
In VMs I tried cirrus and wmvga video drivers, for both the same issue occurs.
Discussed in the 2011-07-29 blocker review meeting. Nobody else has been able to reproduce this issue and the impact is unclear. We decided to wait for more test results and clarification before deciding on blocker status.
Kamil, exactly what boot option(s) were you using to get this behavior?
I am quite surprised no one was able to reproduce it, because I reproduced it on two different bare metal machines (by forcing vesa driver) and also in virtual machines.
I used the default boot options as in items "Boot" and "Boot (Basic Video)", only appending "selinux=0". That is:
"vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-16-Nightly-20110722.09-i6 rootfstype=auto ro liveimg quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 selinux=0"
"vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-16-Nightly-20110722.09-i6 rootfstype=auto ro liveimg quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 xdriver=vesa nomodeset selinux=0"
Unfortunately no new LiveCDs were created since Jul 22nd, so I can't re-test with latest code.
The same happens in VirtualBox. Those who could not reproduce the issue, did they really try to boot the aforementioned LiveCD, or did they just try to boot a previously installed system?
since we didn't get tc1 live images yet, it'd probably be best to wait until we have tc1/tc2/rc1 live images to make a definite decision on this one, I think.
Discussed in the 2011-08-05 blocker review meeting. Agreed to wait for updated test results against live images. If no new updates by next blocker bug review meeting, it will be rejected as an alpha blocker.
This problem is solved with F16 Alpha RC1. Tested both archs in VM.