Red Hat Bugzilla – Bug 679326
Shell only works on second try (likely due to too-short timeout on gnome-session-is-accelerated)
Last modified: 2011-04-06 23:51:47 EDT
Description of problem:
Using a LiveUSB pen I'm working on the nouveau test day. There I noticed a very strange behavior. At the very first time I boot the pen, I get the Gnome 3 fallback. When I boot the pen another time, I'll get the Gnome 3 Shell.
I didn't make any changes, so it's a self-repairing problem. Probably one'd always get the fallback if you use a CD or no overlay.
Version-Release number of selected component (if applicable):
Twice so far
Steps to Reproduce:
1. Setup the iso on a USB pen with an overlay
2. Boot once -> fallback
3. Boot twice -> Shell
Created attachment 480077 [details]
dmesg output after the first boot with drm.debug=0x04
Created attachment 480078 [details]
syslog from after the first boot with drm.debug=0x04
Created attachment 480079 [details]
Xorg.0.log from after the first boot with drm.debug=0x04
Created attachment 480081 [details]
dmesg output after a later boot with drm.debug=0x04
Created attachment 480082 [details]
syslog from after a later boot with drm.debug=0x04
Created attachment 480084 [details]
Xorg.0.log from after a later boot with drm.debug=0x04
I'm seeing the same symptoms on a G86 [GeForce 8400M GS] [10de:0427] (rev a1): http://www.smolts.org/client/show/pub_712c4340-5618-4510-a7d9-ce737712c29c
I'm not attaching output here so as not to munge up this bug accidentally.
I see the same symptoms with G84 (GeForce 8400 GS] pci 10de:0404 (rev a1).
Crash of gnome-user-share seems to be related: crash of g-u-s implies no Gnome3 shell. Abrt > Report insists on downloading 179MB, including gcc-debuginfo (the debuginfo of the _compiler_), which fills up the LiveCD drive.
Same problem with 05:00.0 VGA compatible controller : nVidia Corporation NV43 [GeForce 6600] [10de:0141] (rev a2), including same interaction with gnome-user-share.
Workaround: log out (System > Log out liveuser...) then log back in. Logging back in seems to require clicking the Login button; typing '\r' did not work for me. But I got Gnome Shell instead of the fallback.
Feb 22 10:38:05 localhost abrt: saved core dump of pid 1611 (/usr/libexec/gnome-user-share) to /var/spool/abrt/ccpp-1298389084-1611.new/coredump (1318912 bytes)
Feb 22 10:38:05 localhost abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1298387534-1824)
Feb 22 10:38:05 localhost abrtd: Deleting crash ccpp-1298389084-1611 (dup of ccpp-1298387534-1824), sending dbus signal
Feb 22 10:38:09 localhost abrt: saved core dump of pid 1651 (/usr/libexec/notification-daemon) to /var/spool/abrt/ccpp-1298389089-1651.new/coredump (21270528 bytes)
Feb 22 10:38:09 localhost abrtd: Directory 'ccpp-1298389089-1651' creation detected
Feb 22 10:38:09 localhost abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1298388027-1650)
Feb 22 10:38:09 localhost abrtd: Deleting crash ccpp-1298389089-1651 (dup of ccpp-1298388027-1650), sending dbus signal
I'm guessing that the gnome-user-share problem is where we should start tackling this issue. That issue is already filed as bug#677555
When logging into gnome-shell works okay, does gnome-user-share still crash? Meaning, is the gnome-user-share crash causing the login problem?
On four different machines each with a different model NV card (6600, 8400GS, 9400GS, GT210), what I see is: gnome-user-share crashes if and only if the fallback gets invoked (and not Gnome shell.) The workaround (log out, log back in (do not reboot)) always works for me.
I'm booting from an optical disc, and get fallback when logging in for the first time. Any later login (either logging out and back in, or logging in as a different user) gets Gnome shell. It doesn't matter whether I log in by clicking the Login button or by hitting Enter.
*** Bug 679685 has been marked as a duplicate of this bug. ***
Have same problem on M92 [Mobility Radeon HD 4500 Series]
More info - https://bugzilla.redhat.com/show_bug.cgi?id=679685
*** Bug 679488 has been marked as a duplicate of this bug. ***
displays "Bug #641992 does not exist" so the External Tracker bug ID on this bugzilla report does not help.
that's because I'm an idiot, and it's a GNOME bug. =) fixing
Same issue working from the test day live CD on a Samsung NC10 netbook (external USB DVD-RW): http://www.smolts.org/client/show/pub_6addbf83-d0f4-47c5-8219-d88d2c00e5aa
Behaviour of fallback as per John Reiser's comments above: "gnome-user-share crashes if and only if the fallback gets invoked (and not Gnome shell.)"
For me this happened about half the time, not always on the first login, sometimes on subsequent logins, but logging out and back into Gnome would eventually load the shell properly.
Fallback always accompanied by gnome-user-share crash: https://bugzilla.redhat.com/show_bug.cgi?id=677555
Now here (rawhide, not branched 15; x86_64) I always get fallback
That's funny, in contrast to what Horst describes: I haven't seen fallback on the system in questions for quite a while - I'd even think it's always been Shell for nearly a week now.
But there's a difference between my initial report and the situation now: I no longer use the usb pen but installed the system instead. So my initial report might be a live system related bug of sorts.
sandro: live system boot is usually going to be slower than an installed system boot, and this is a highly speed-dependent bug...
Fedora Bugzappers volunteer triage team
Adam: I haven't read anything in this bug so far that says "this is highly speed-dependent" - but now you've said it, it pretty obviously is - so this is some sort of a race condition on the live media again. Just as with bug 679486...
(In reply to comment #23)
> That's funny, in contrast to what Horst describes: I haven't seen fallback on
> the system in questions for quite a while - I'd even think it's always been
> Shell for nearly a week now.
> But there's a difference between my initial report and the situation now: I no
> longer use the usb pen but installed the system instead. So my initial report
> might be a live system related bug of sorts.
My experience: I (briefly) used Gnome shell up to around February 3 or 4. Then GDM and Gnome went south here. I went on vacation, using XDM and XFCE afterwards from February 12 or so. Tried Gnome on and off until today, no way to get it working. When I tried the one for the graphics test, Gnome from disk still didn't work for my account, and the on the LiveCD had to be restarted to go to the shell. Now Gnome fallback works from disk (GDM is still shot), and I was informed that my graphics card wasn't up to the task the first time I started Gnome again. I can't get Gnome shell (Perhaps the logout/login process is diferent here? It doesn't work started from XDM?).
sandro: it's not, strictly speaking, a race condition, it's just a timeout. gnome-session-is-accelerated, which is a test script to figure out if the current environment (graphics card, driver, mesa etc) can support GNOME Shell, has an arbitrary timeout to stop it taking too long; after the timeout expires it assumes the test failed and goes to fallback mode. The current timeout is very short, so it's being hit in many cases where, if it were a bit longer, the test would complete and pass successfully.
There's more detail in the upstream bug.
horst: if you can't get Shell by running gnome-shell --replace , then this is not your bug. This bug is only for the case where the fallback mode kicks in because of the test timeout issue noted above, but actually Shell would work fine.
*** Bug 675481 has been marked as a duplicate of this bug. ***
(In reply to comment #27)
> horst: if you can't get Shell by running gnome-shell --replace , then this is
> not your bug. This bug is only for the case where the fallback mode kicks in
> because of the test timeout issue noted above, but actually Shell would work
I had the exact same symptoms with the live CD. Now, with the installed rawhide (16) system I only get fallback, and:
$ gnome-shell --replace
failed to create drawable
Window manager error: Unable to initialize Clutter.
Cannot register the panel shell: there is already one running.
compiz (core) - Error: Screen 0 on display ":0.0" already has a window manager; try using the --replace option to replace the current window manager.
Window manager warning: Failed to load theme "Nodoka": Failed to find a valid file for theme Nodoka
Fixed here now (same machine, clean install of Fedora ~~-> 15)
Considering this fixed, we do have longer timeouts now.