Description of problem: When I login from gdm, I get the not very useful "oh no!" error. If I run: xinit I get a shell. I can replace the desktop with gnome-shell. If I run: xinit gnome-shell I get the gnome desktop. But if I run: xinit gnome-session I get a crash. More info to follow. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Here are the errors which go to the console before it all crashes (transcribed from video): gnome-settings-daemon:4047 color-plugin-WARNING **: failed to create device: failed to obtain org.freedesktop.color-manager.create-device auth gnome-settings-daemon:4047 color-plugin-WARNING **: failed to obtain org.freedesktop.color-manager.create-profile auth gnome-settings-daemon:4047 color-plugin-WARNING **: failed to obtain org.freedesktop.color-manager.create-profile auth ** Bluetooth:ERROR:rfkill-glib.c:83:type_to_string: code should not be reached gnome-session[4013]: WARNING: Application 'gnome-shell.desktop' killed by signal 6 gnome-session[4013]: WARNING: App 'gnome-shell.desktop' respawning too quickly and then some GLib-CRITICAL errors - do you need these too?
Open new bug 962351 for new error about wacom.
Reporter - can you attach the ~/.xsession-errors file , and possibly stuff from /var/log/gdm if it looks interesting? Thanks.
I don't have an ~/.xsession-errors file, but will attach what I have.
Created attachment 748152 [details] gdm log
Created attachment 748153 [details] xorg log
I think we really need xsession-errors :/ Maybe I should be a bit more specific: try to reproduce the problem, so you see the "Oh no!" screen, and at that point switch to a console and look in your home directory for a file .xsession-errors (it is of course a hidden file). I suppose "Bluetooth:ERROR:rfkill-glib.c:83:type_to_string: code should not be reached" may be the fatal error here (though I really wanted to see xsession-errors to get more context). Do you have a Bluetooth adapter? If so, can it be disabled or removed? Does that work around the problem? Thanks!
There really is no ~/.xsession-errors, which is admittedly odd. What if I were to run xinit then run gnome-session from the terminal, and give you the output from that? I will try disabling bluetooth in the bios. If that fails I will rmmod it.
You could try 'journalctl -a', that may have the info.
Created attachment 748626 [details] journalctl -abf --lines=0
I blacklisted bluetooth and rebooted. That log shows everything from when I killed gdm onwards.
I ran a yum remove colord, then I ran yum install colord. No change.
Does it work if you boot with "enforcing=0"?
I will try. There is nothing in the audit log, and setenforce 0 beforehand doesn't help.
btw deleting the ~/.xsession-errors on other computers also seems to prevent it from ever being created again.
enforcing=0 does not help. I have new logs, I'll post them.
Created attachment 749260 [details] gdm log :0.log
Created attachment 749261 [details] xorg :0.log
Created attachment 749262 [details] xorg :0.log.1
There's nothing much in there, the journalctl seemed like the interesting thing. I guess the bluetooth error is still our main suspect. Can you attach the latest journalctl? But I think we need Ray or another of the GNOME folks to look through the logs and figure out what's going on here.
I will attach the latest journalctl on Tuesday morning.
btw I have bug 962351 open for the wacom critical error. Reinstalling colord does not help the "Error creating directory: Permission denied" error. I can do nothing about the tracker error, it has too many dependencies to remove and forcing it prevents gnome from working. bluetooth is currently blacklisted. yum check reveals no problems.
Created attachment 750913 [details] journalctl
Just tried to install Fedora 19 beta RC4, and the installer crashed with the same problem. Unfortunately I didn't capture the log files since there was not enough time.
The logs at /tmp/*log do not capture any information related to the gnome crash. What do you want me to do? That was a fresh install attempt.
Still waiting for the GNOME devs to take a look, I'm afraid :( I can't get a lot further with this one.
It's a crash (assert) in the rfkill handling code. kernel 3.9 added some new RFKILL_TYPE enum types, but gnome-bluetooth's rfkill code only handles the older types. There's a changeset in git that fixes this; I'll ask hadess on Monday if we can have a new gnome-bluetooth release. P.S. I'm mildly annoyed by the aggressive kernel updates in older releases. Looks like F17 is getting kernel 3.9 as well and we'll have to patch at least gnome-bluetooth and control-center to fix crashes with the new kernel version.
Doesn't the upstream kernel have a stated policy that 'if something worked with an older kernel and doesn't work now, that's a kernel bug'? anyhow. https://fedoraproject.org/wiki/KernelRebases explains the thinking behind rebasing the kernels of stable releases; it kinda makes sense to me, though sometimes it does cause inconvenience. This seems like something we'd definitely want fixed ahead of 19 release, and backported to 17 and 18...
Same problem here with hp8510w notebook. Crash with gnome ad cinnamon after f19 upgrade, Ok with lxde
Same problem here, with gnome-shell. journalctl -ba shows the bluetooth error. HP8530w
Same problem here on HP6730b notebook
gnome-bluetooth-3.8.1-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-bluetooth-3.8.1-1.fc19
The package gnome-bluetooth-3.8.1-1.fc19 fixed my problem. Thanks!
Won't be able to test until end of week. btw I'm going to use this bug as an example whenever I'm told that because nobody else is having the problem, I must be the only one - twenty two days until a confirmed report (thanks Kalev Lember)
I don't think anyone said that in this case.
Throw this on the final blocker list just to be safe, conditional violation of https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_installed_system_boot_behavior for affected systems (looks to be various HP laptops).
(In reply to Adam Williamson from comment #28) > This seems like something we'd definitely want fixed ahead of 19 release, > and backported to 17 and 18... F18 already has the fix in stable updates, and here's the F17 update: https://admin.fedoraproject.org/updates/gnome-bluetooth-3.4.2-2.fc17
Awesome. I'll try and get the f17 update some karma. Thanks.
ok for me too (hp 8510w) after upgrade. Thank you I had to manually download and install the package from the link provided above, because yum (even after yum clean all) did not find this specific upgrade (only others)
It takes a bit of time for a newly-submitted update to actually appear in a tree compose and then make its way out to the mirrors. As long as the upgrade worked for you, that's great: can you add karma to it? See https://fedoraproject.org/wiki/QA:Updates_Testing for details. Thanks!
Package gnome-bluetooth-3.8.1-1.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 gnome-bluetooth-3.8.1-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10044/gnome-bluetooth-3.8.1-1.fc19 then log in and leave karma (feedback).
karma added.
Discussed at 2013-06-05 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-05/f19final-blocker-review-3.2013-06-05-16.05.log.txt . Accepted as a blocker per https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_installed_system_boot_behavior : "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. " in the case that you have affected hardware (of which there seems to be quite a lot).
gnome-bluetooth-3.8.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.