Created attachment 704448 [details] Output of « journalctl » Description of problem: I'm trying to boot the (as of today) latest Rawhide nightly: http://koji.fedoraproject.org/koji/taskinfo?taskID=5053318 I just boot it, and all I get is the GNOME fail screen. Not sure what is the component causing the problem, so I'm reporting it against LiveCD, I guess we can move from there to the appropriate one. I'm attaching the output of journalctl, let me know if something else is needed.
FWIW I have been seeing this for now over 2+ weeks. And also happens for guest net installs at least so is not Live specific.
(In reply to comment #1) > FWIW I have been seeing this for now over 2+ weeks. > > And also happens for guest net installs at least so is not Live specific. So, the thing is, you speak about guests, which makes me think you are talking about virtual machines. I think this is a different bug, though. Indeed, I have also seen that Rawhide (even installed) produces the same symptoms as described here on virtual machines, without exception. However, the bug I reported is for Live media running on a **physical** machine. And I'm writing this message from Rawhide, installed on a physical machine, running perfectly. So, the problems are: - on physical machines, Live media doesn't work (the bug I reported here) - in virtual machines (Boxes in my case, no idea what you tested on), neither Live nor installed work I wouldn't be surprised if these are two different problems.
(In reply to comment #1) > And also happens for guest net installs at least so is not Live specific. For net installs I run into a different problem, see bug#917497
Fresh F19 install today still boots to a fail dialog for me in both virt-manager guest and intel laptop (T500). Proposing as F19Alpha Blocker.
(A workaround BTW is to use startx to run a desktop session.)
Actually the gnome fail dialog I am seeing seems related to gnome-initial-setup: if I remove gnome-initial-setup then instead of a gnome fail dialog I see gdm looping until it finally gives up. startx runs gnome fine.
mathieu: can you confirm Jens' finding? If so we should move this to be against gnome-initial-setup.
Mar 02 04:12:52 localhost kernel: gdm-simple-slav[836]: segfault at 0 ip 08053d4d sp bfc7ed30 error 4 in gdm-simple-slave[8048000+44000] ^ GDM is crashing, we need a stack trace.
jens: mathieu: you should be able to find it running 'abrt-cli' as root.
Created attachment 712229 [details] backtrace of gdm-simple-slave Here's the backtrace.
(In reply to comment #7) > mathieu: can you confirm Jens' finding? If so we should move this to be > against gnome-initial-setup. Not at all. The bug I had initially opened was only that GDM was crashing **on the live CD**, and only the live CD, as I have been running an installed Rawhide for a while on another laptop, and GDM has not crashed even once there. The bug then got somehow moved to something else: that GDM is crashing for some people on the installed system. I have no idea if that is the same bug as what I reported initially.
(Sorry I might have partially hijacked this bug.) Anyway let me file a separate one for the gnome-initial-setup fail dialog.
Jens: I believe that would be https://bugzilla.redhat.com/show_bug.cgi?id=922951 . Mathieu, does adding gnome-session-xsession to the live image fix your issue?
(In reply to comment #13) > Mathieu, does adding gnome-session-xsession to the live image fix your issue? Great call, it fixes the problem for me.
I've already added it to comps, but I'd like to verify it's the same issue for Mathieu before we close the bug.
Ah good, and Kamil already filed the gnome-initial-setup bug 922951.
(In reply to comment #13) > Mathieu, does adding gnome-session-xsession to the live image fix your issue? I just tried creating two live images, using: - fedora-livecd-desktop.ks, to check the bug is still in the current F19 - just adding gnome-session-xsession to the previous kickstart In the first case, I got bug 917304. In the second case, the boot never finishes, I keep getting lots of Kernel Oopses. So I'm not even getting to the point where the bug occurred. :-/
(In reply to comment #15) > I've already added it to comps, but I'd like to verify it's the same issue > for Mathieu before we close the bug. Comps? Something is weird here. gnome-session-xsession contains a single desktop file, to register into gdm, IIUIC. So shouldn't this be rather fixed by RPM dependencies, where gnome-session could require gnome-session-xsession? (Why is the desktop separated?). Or maybe we can fix this is comps, but then gdm shouldn't crash if the desktop file is not present, but rather say something like "no sessions available to choose from"? If we "fix" a crash by adjusting comps, isn't that a bit fallible? People can remove the package by accident and then gdm would crash for them again.
gnome-session-xsession requires gnome-session, but sure, I don't mind a cleaner fix. You're right that ideally gdm should handle it gracefully rather than crashing, although the ultimate practical effect would be the same unless you have other desktops installed.
mathieu: try disabling plymouth to avoid the kernel oopses.
(In reply to comment #20) > mathieu: try disabling plymouth to avoid the kernel oopses. Disabling it, all I get is a kernel panic... (just to be sure, the right method to disable Plymouth is just to remove the "quiet" option from the boot parameters, right?)
No. Try 'plymouth.enable=0', I think.
So we're declaring this to be the bug for the "gnome-session-xsession has to be installed for gdm to transition to GNOME" issue. Mathieu, please file new bugs for any other issues you're now experiencing. Discussed at 2013-03-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-20/f19alpha-blocker-review-2.2013-03-20-16.00.log.txt . Accepted as a blocker per criterion "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." That is addressed by the change I did to comps, but Kamil has a point that this may not be the best fix. Owen, desktop team, would you like to change how this is addressed, or are you okay with the comps fix?
One also needs to remove /var/lib/gdm/run-initial-setup in addition to gnome-initial-setup for "gdm" to startup. (In reply to comment #18) > Comps? Something is weird here. gnome-session-xsession contains a single > desktop file, to register into gdm, IIUIC. So shouldn't this be rather fixed > by RPM dependencies, where gnome-session could require > gnome-session-xsession? (Why is the desktop separated?). Or maybe we can fix > this is comps, but then gdm shouldn't crash if the desktop file is not > present, but rather say something like "no sessions available to choose > from"? It should be separate because gnome-shell can start other sessions than just standard gnome-shell, eg gnome-classic-session (and traditionally :( many other desktops too). So this is quite correct. However I concede the naming is not ideal: gnome-session-xsession should probably be renamed to gnome-shell-xsession or something like that.
Given the solution this bug could probably be moved to comps.
Jens: well, Kamil's point is that 'fixing' it in comps is not necessarily correct. And it certainly seems like a bug that GDM simply crashes if there's no session.
Dropping blocker nomination now: putting this in comps fixes the blocker problem. Leaving bug open for now in case anyone wants to fix it differently.
It might be worth retesting with gdm-3.8.0.
gnome-shell now has a dep on gnome-session-xsession, so I guess we can call this fixed...
For the record: we have decided to take the dependency back out of gnome-shell. Here's the reasoning. GDM requires gnome-shell. If gnome-shell requires gnome-session-xsession, you will have a GNOME X session any time you have GDM installed, even if you don't actually have the rest of GNOME installed. This affects any case where you want to use GDM as the login manager for some other desktop. Specifically, the SoaS spin still uses GDM as its login manager. This change caused the SoaS spin to boot to a basically useless GNOME Shell instead of to Sugar, since both gnome.session and sugar.session get installed, and for autologin, gnome.session wins. We could make Sugar the default session for the *live* boot easily enough, but it's harder (or impossible) to cleanly make Sugar the default session OOTB for the post-install system if both gnome.session and sugar.session are present. So basically, given the above, we figured it wasn't really correct for gnome-shell to depend on gnome-session-xsession, since there's a legitimate case for having gnome-shell package installed but not actually having or wanting a complete GNOME desktop: the case where you're using GDM as a login manager for something else. Kamil's concerns from c#18 are valid, but adding a dep to gnome-shell doesn't seem the best way to address them. If we want to address that issue we could have all packages containing X session files provide, say, 'desktop-xsession' and have GDM just require 'desktop-xsession', or we could make GDM fail gracefully somehow if no session is installed. But it doesn't seem urgent, since you have to try quite hard to wind up with the 'no sessions at all' case now we've added gnome-session-xsession to comps. The dep was removed again in gnome-shell-3.8.2-3.fc19 .