Description of problem: After I login with gdm, I get a notice covering the lower half of my screen with the Oh no somethings gone wrong notice. This started with 3.7.5 and had been working with 3.7.4. Version-Release number of selected component (if applicable): gnome-shell-3.7.5-2.fc19.i686 How reproducible: Happens all of the time. Additional info: I have a radeon 9200 (based on an rv280). I have forced fallback mode set, so I am probably getting a different window manager now.
I turned off forced fallback (in both gdm and gnome) and see the same behavior. I had gdm using forced fallback, because there was a period when gdm was failing and using gdm-fallback worked around the problem.
I am now seeing the fail whale message instead of a background image with gdm (now at gdm-3.7.90-1.fc19.i686). However gdm still works and I can use it to login to xfce.
r200 based cards are blacklisted. I tried removing the blacklist entry, but things failed harder (I no longer saw the login window). It looks like there is supposed to be a fallback to llvmpipe, but that doesn't appear to work correctly.
The fail whale page is showing up in gdm again, except now I can't login. I am using kdm as a work around now to do graphical logins.
*** Bug 919743 has been marked as a duplicate of this bug. ***
CCing ajax for his expert input here. So really the bug here is that when your mesa driver is blacklisted, llvmpipe should be used as a fallback to do software rendering of GDM and Shell, but it isn't. ajax writes: "it's somewhat icky to fix. libGL has a wart where it doesn't cope like you'd hope if you suddenly set LIBGL_ALWAYS_SOFTWARE=1 while your process is running. so you kinda need to run session-check-is-accelerated-helper-helper-helper twice, once with and without, and pass knowledge of which one succeeded back up the chain" so I assign it to gnome-session. Discussed at 2013-03-13 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-13/f19alpha-blocker-review-1.2013-03-13-17.02.log.txt . Whether this is a blocker is a judgement call based on how much hardware is affected. The amount of blacklisted hardware likely still to be in use is relatively small, so we decided it's appropriate to make it a Beta blocker, and a freeze exception for Alpha. The criterion is "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" (current criteria) or "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot." (adamw's pending rewrite).
The reason this becomes more urgent in F19 is that GNOME 3.8 drops the non-accelerated 'fallback' sessions for GDM and GNOME.
If you see this you can use the following work around. CA-F2 to get a vt. Login as root. Install kdm if it is not already installed (yum install -y kdm). Stop gdm. This may switch which vt is showing on the console. systemctl stop gdm CA-F2 Start kdm. This may leave a root session open on the vt which you'll wan to close. systemctl start kdm CA-f2 Make the change persist. systemctl disable gdm systemctl enable kdm logout Then switch back to kdm. Usually it we be on 1, but if not try others. CA-F1
Another note about the work around. This won't let you use gnome. You will need to choose some other desktop in kdm before logging in. If you don't have any already installed you can use yum groupinstall xfce-desktop to install xfce.
I tried this with gnome-session-3.8.0-1.fc20.i686 and got: Mar 27 14:31:43 bruno gdm[2262]: GLib: g_variant_compare: assertion `!g_variant_is_container (a)' failed Mar 27 14:31:43 bruno gdm[2262]: GLib: g_variant_compare: assertion `!g_variant_is_container (a)' failed Mar 27 14:31:47 bruno /usr/bin/dbus-launch[2380]: gnome-session-is-accelerated: No hardware 3D support. Mar 27 14:31:47 bruno /usr/bin/dbus-launch[2380]: gnome-session-check-accelerated: Helper exited with code 256 Mar 27 14:31:53 bruno /usr/bin/dbus-launch[2380]: gnome-session-is-accelerated: No hardware 3D support. Mar 27 14:31:54 bruno /usr/bin/dbus-launch[2380]: gnome-session-check-accelerated: Helper exited with code 256 Mar 27 14:31:54 bruno /usr/bin/dbus-launch[2380]: ** (process:2380): WARNING **: software acceleration check failed: Child process exited with code 1 Mar 27 14:32:19 bruno systemd[1]: Stopping GNOME Display Manager... Mar 27 14:32:19 bruno systemd-logind[992]: Removed session c1. Mar 27 14:32:19 bruno gdm[2262]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed Mar 27 14:32:19 bruno gdm[2262]: GLib-GObject: g_object_unref: assertion `object->ref_count > 0' failed Mar 27 14:32:19 bruno systemd[1]: Stopped GNOME Display Manager.
(In reply to comment #10) > gnome-session-check-accelerated: Helper exited with code 256 Seeing this twice is pretty weird. Please attach the output (is-accel.t) from running: $ LIBGL_ALWAYS_SOFTWARE=1 strace -o is-accel.t /usr/libexec/gnome-session-check-accelerated-helper
Created attachment 730940 [details] strace output
(In reply to comment #12) > Created attachment 730940 [details] > strace output The part where the failure kicks in is: ... open("/usr/share/gnome-session/hardware-compatibility", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=773, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77f4000 read(4, "##\n## This file contains a list "..., 4096) = 773 close(4) = 0 munmap(0xb77f4000, 4096) = 0 ... After that we go start tearing everything down, so it _appears_ that you're hitting the renderer blacklist. That could happen if the llvm part of llvmpipe failed to init (in which case it would claim to be softpipe), or if the blacklist file doesn't contain what we think it contains. Please attach the output from 'LIBGL_ALWAYS_SOFTWARE=1 glxinfo', and /usr/share/gnome-session/hardware-compatibility and /proc/cpuinfo from the affected machine.
Created attachment 731210 [details] glxinfo output
Created attachment 731212 [details] blacklist output
Created attachment 731213 [details] cpuinfo
There we go: (In reply to comment #14) > Created attachment 731210 [details] > glxinfo output OpenGL renderer string: Gallium 0.4 on softpipe (In reply to comment #16) > Created attachment 731213 [details] > cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow llvmpipe requires SSE2 at the moment, so, that's unfortunate. I'm not sure whether that's justified; I'll bring up a 32-bit vm and mask off sse2+ and see if I can get things going. I'll also try to find a 3dnow-but-not-sse2 machine and see whether there's any performance increase to be had from using 3dnow.
(In reply to comment #17) > llvmpipe requires SSE2 at the moment, so, that's unfortunate. I'm not sure > whether that's justified; I'll bring up a 32-bit vm and mask off sse2+ and > see if I can get things going. Seems to work for me on an Athlon XP 2600+, which is approximately as featureful as what you've got. New Mesa build with the fix to follow shortly.
I'm going out tonight so I'll either test it pretty late tonight or tomorrow morning. I'll also test it on a pentium M laptop that I think has roughly the same issue.
I tested mesa-9.1-5.fc20 a little tonight and I get a functioning (if slow) gnome shell desktop working. I only tried this on the rv280 machine. Tomorrow I'll look at the intel machine and try out gdm on both.
I did some more testing on the rawhide / Althon / rv280 system. I had a crash in gnome-classic. gdm only sort of works. When the background image showed I couldn't see the login menu except very briefly if I clicked with the mouse in the right place. When the background image didn't show (which is more likely a gdm issue) then I could see and use the login menu. There was also odd color stuff that may or may not be the driver. Things would mostly be grayscale (except for the background image) but occasionally clicking on things (such as scroll bars) would get an object to be colored (usually a blue). That may be just the look though. I haven't been able to use gnome for a while and was using fallback when I did. gnome and gnome classic were hard to use because of slow response, but that is probably expected given the cpu is being used for graphics. I also saw a problem logging into xfce from gdm. I eventually gave up and stopped gdm, started kdm and logged in. Logging into gnome from kdm worked better and gnome seemed to have less issues (like having more color) when I did it that way. I did see the fail whale page once logging into gnome, but there might have been a mix of xfce and gnome stuff running at the time. I'll try to get some testing of f19 / pentium M laptop today, but I need to do some other stuff first.
So I found some partial answer on why testing gdm was hard. gnome-initial-setup is running. The graphics for it aren't really usable on my athlon system, but it does reasonable on the pentium M laptop. Once I figure out how to not trigger gnome-initial-setup when using gdm instead of kdm, I'll try it again. gnome-classic looks OK on the pentium M machine. gnome logins result in the fail whale page, but I can't easily tell if this is from graphics or something else.
xorg-x11-drv-ati-7.1.0-4.20130408git6e74aacc5.fc19, mesa-9.1-6.fc19, xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-5400/mesa-9.1-6.fc19,xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19,xorg-x11-drv-ati-7.1.0-4.20130408git6e74aacc5.fc19
Package mesa-9.1-6.fc19, xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19, xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mesa-9.1-6.fc19 xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19 xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5400/mesa-9.1-6.fc19,xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19,xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19 then log in and leave karma (feedback).
sudo rm -f /var/lib/gdm/run-initial-setup should stop initial-setup from running
can we get some testing on the update so it can potentially be in the next alpha build? Thanks!
On current (synced this morning) rawhide on the Athlon MP with ATI 9200 (rv280) machine gdm is mostly gray scale with one button turning blue at some point. After authenticating X eventually stops before I get a graphics session (neither Gnome nor XFCE worked) and the console output is displayed again. On f19 + updates-testing (synced this afternoon) on a Pentium M with motherboard video I can now use gdm to login to gnome-classic. I didn't do testing in gnome-classic once I got the desktop displayed. Redraws were not happening in gdm properly. The background was initially console output. When I used menus, the menu display didn't go away when it should. The color looked normal. I also got the old gdm display rather than the new one. When I tried to login to a gnome session I got the fail whale page. But logging into gnome-classic got me a normal looking desktop. So while this is better than it was, I wouldn't recommend pulling it just for this fix. On the other hand it didn't seem to make things worse for KDM + XFCE.
Created attachment 735017 [details] glxinfo from pentium M machine
Created attachment 735018 [details] cpuinfo for pentium M machine
Created attachment 735020 [details] is-accel.t from pentium M machine
Created attachment 735021 [details] hardware-compatibility from pentium M machine
(In reply to comment #26) > can we get some testing on the update so it can potentially be in the next > alpha build? Thanks! The testing I did in comment #12 was against Xvnc on a non-SSE2 machine. It's probably worth testing the Xvnc and Xorg paths separately here though.
mesa-9.1-6.fc19, xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19, xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
ajax: given Bruno's feedback in c#27, should we re-open this? Or ask him to file a new one?
Related: https://bugzilla.redhat.com/show_bug.cgi?id=917726 for Fedora 18.
Bruno: at a QA meeting a couple of weeks back you said you'd check this again with Beta, did you do so? Is it working better now? Thanks!
I tried to test this in a VM but the virt-manager CPU feature configuration stuff seems kinda screwed ATM so I couldn't get it to fly...
Tonight I check this is rawhide (as that's what my machine with the ATI 9200 runs) and both gdm and gnome failed with the Oh No! screens. kdm and xfce work fine. About a week ago I had tried the intel machine with a live games image and it seemed to work OK.
can you test it with an F19 Beta live image? rawhide is somewhat diverged from F19 at this point, so it would be more useful. thanks!
I tested this with Fedora-Live-Desktop-i686-19-Beta-1.iso on a DVD (can't boot with USB on this machine). In less than a second after clicking on try Fedora I got the Oh no somethings gone wrong screen. I doubt this is affecting enough people on final to make it a blocker. Probably gnome will be too slow anyway. A common bug or something suggesting xfce is probably a good enough solution.
Marking as requiring a release note: docs team, the release note here should be broadly what Bruno said in comment #40. If you have a system with a CPU old enough that it doesn't have SSE2 extensions (so, I think, pre-Pentium 4 or pre-Athlon 64) and a graphics card old enough that it is not capable of hardware accelerating Shell (so, Intel older than 9xx, Radeon older than R300 (Radeon 9500), NVIDIA older than NV30 (GeForce FX5xxx)), then you're very likely not to be able to get a working Shell at all. And as Bruno points out, even if it worked, the experience would probably be a bit painful. So we recommend you use another desktop instead; KDE is the most strongly supported, Xfce or MATE would be closest to the GNOME 2 / GNOME 3.6 "fallback" environment.
I've added a note to the Hardware Overview section of the release notes. Thanks Adam!