Bug 723160 - Gnome-shell presents enormous warning dialog
Summary: Gnome-shell presents enormous warning dialog
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F16Alpha, F16AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2011-07-19 09:15 UTC by Kamil Páral
Modified: 2011-08-08 08:06 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-08 08:06:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
screen after boot with enormous dialog (35.49 KB, image/png)
2011-07-19 09:15 UTC, Kamil Páral
no flags Details
dmesg (42.79 KB, text/plain)
2011-07-19 09:16 UTC, Kamil Páral
no flags Details
logs (660.00 KB, application/x-tar)
2011-07-19 09:16 UTC, Kamil Páral
no flags Details
Screenshot.png (345.38 KB, image/png)
2011-07-22 16:04 UTC, James Laska
no flags Details
bug demonstration video (545.92 KB, video/ogg)
2011-07-25 08:31 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2011-07-19 09:15:59 UTC
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-[1323]: 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-[1332]: 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-[1328]: 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-[1477]: 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[1601]: 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):
Fedora-16-Nightly-20110718.08-x86_64-Live-desktop.iso
(http://koji.fedoraproject.org/koji/taskinfo?taskID=3207004)


How reproducible:
always


Steps to Reproduce:
1. Boot the ISO in virt-manager.
  

Additional info:
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)"
https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria

Comment 1 Kamil Páral 2011-07-19 09:16:39 UTC
Created attachment 513741 [details]
dmesg

Comment 2 Kamil Páral 2011-07-19 09:16:55 UTC
Created attachment 513742 [details]
logs

Comment 3 Kamil Páral 2011-07-22 07:59:46 UTC
After discussion with adamw marking also as F16Alpha-NTH.

Comment 4 James Laska 2011-07-22 16:04:11 UTC
Created attachment 514732 [details]
Screenshot.png

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?

Comment 5 Tim Flink 2011-07-22 22:07:11 UTC
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?

Comment 6 Kamil Páral 2011-07-25 08:30:26 UTC
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.

Comment 7 Kamil Páral 2011-07-25 08:31:21 UTC
Created attachment 514988 [details]
bug demonstration video

Comment 8 Adam Williamson 2011-07-25 22:24:38 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 9 Adam Williamson 2011-07-25 22:25:51 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 10 Kamil Páral 2011-07-26 08:42:18 UTC
(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.

Comment 11 Tim Flink 2011-07-29 17:43:09 UTC
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?

Comment 12 Kamil Páral 2011-08-01 09:15:59 UTC
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"

and

"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.

Comment 13 Kamil Páral 2011-08-01 09:45:26 UTC
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?

Comment 14 Adam Williamson 2011-08-05 05:13:30 UTC
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.

Comment 15 Tim Flink 2011-08-05 17:48:49 UTC
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.

Comment 16 Kamil Páral 2011-08-08 08:06:40 UTC
This problem is solved with F16 Alpha RC1. Tested both archs in VM.


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