Bug 741075

Created attachment 524759 [details]
messages with debug while loading GDM

Same message appears if I use KDM and then I try to login into GNOME3. 

Just to provide more info I have a Nvidia 6150 and I'm using the nouveau driver

Created attachment 524760 [details]
messages with debug while loading GNOME

I had the same problem lately, please run
rpm -q caribou
and paste the output.
If you have i686 caribou, you need to remove it with rpm -e --nodeps and then install the x86_64 version.
That fixed the problem for me.

Elad, thanks that is a workaround for my GDM problem. GNOME problem still persist. I will open a separate bug for it.

my GNOME problem is solved now. I just remove everything on ~/.config/autostart.

I will keep this BZ open just i case GDM developers want to study why caribou.i686 was installed instead of caribou.x86_64 causing GDM to crash.

I'm using GDM.  I updated from F15 to F16.

I get the 'log out' screen each time I try to login.  This is true even for a new uesr account, which only has default settings.

Also using GDM, wasn't initially having this problem after updating from F15 to F16 beta, but I am after installing some updates last week.

GDM starts, but I get the "Oh no!" screen the first time I log in.  Click Log out, GDM comes back, I login again and then things work fine.

My install is x86_64 architecture and I do not have caribou.i686 installed.  I also have SELinux disabled.  I blew out all the files in ~/.config/autostart/ and this still happens.

Current versions: gnome-shell-3.2.0-2.fc16, gdm-3.2.0-2.fc16 (both x86_64)

I have a number of gnome-shell extensions enabled: GPaste, User Themes, Native Window Placement, Places status indicator, Alternative status menu.  AlternateTab is installed but disabled.

My .xsession.errors file doesn't seem to contain anything of note either.

I'd like this bug to be proposed as a blocker: updgrading from F15 and gnome is almost never usable due to this log out screen that pops up.  What's the right way to do it?

two weeks ago was the right time to propose it as a blocker, not three days after we were supposed to release RC1.

the report seems very confused and there doesn't seem to be any particularly useful analysis of exactly what's going wrong, and it doesn't seem to affect very many people. we could do with some more details. for a start, that message comes from GNOME, not GDM, so why is the bug assigned to gdm?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

so, this error is shown by gnome-session when any critical component of the GNOME session respawns more than once within a minute. The offending component is always mentioned in ~/.xsession-errors .

So for all those affected, please try to log in, *leave* your system sitting at the 'oh no!' screen, switch to a console with ctrl-alt-f3, log in, and take a copy of ~/.xsession-errors , then attach it to this report, so we can see what's crashing.

You can look in ~/.xsession-errors and you should see a line like 'foobar is respawning too fast', or something along those line. 'foobar' is the component that's crashing. If possible, please then try and figure out why: abrt may well have a report for it, or you can try running it from a VT with 'DISPLAY=:0 command' and see what errors you get.

Did anyone affected create a color profile for any piece of hardware with gnome-color-manager in F15? If so, you are likely suffering from https://bugzilla.redhat.com/show_bug.cgi?id=741549 .



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

matias: for your caribou issue, it can happen if the i686 and x86_64 mirrors get out of sync. it shouldn't always happen, though.

Yes, the GDM issue got solved by installing caribou.x86_64 because caribout.i686 got installed instead in my x86_64. It you say it shouldn't always happen I am OK, we can close this bug.

Created attachment 530783 [details]
.xsession-errors

.xsession-errors.  This still happens with gnome-shell-3.2.1-1.fc16.x86_64

matias: yeah, it looks like we could probably close your issue, but amit has kinda hijacked your bug and I'd like to figure out what's happening to him.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

(gnome-settings-daemon:18042): color-plugin-WARNING **: Failed to CreateProfile: The connection is closed

(gnome-settings-daemon:18042): color-plugin-WARNING **: failed to create device: The connection is closed

(gnome-settings-daemon:18042): color-plugin-WARNING **: failed to get devices: Failed to GetDevices: The connection is closed
Gtk-Message: Failed to load module "pk-gtk-module"
** (process:18152): DEBUG: anerley-account-starter.c:86: Online = yes
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

(gnome-settings-daemon:18066): color-plugin-WARNING **: Failed to CreateProfile: The connection is closed

(gnome-settings-daemon:18066): color-plugin-WARNING **: failed to create device: The connection is closed

(gnome-settings-daemon:18066): color-plugin-WARNING **: failed to get devices: Failed to GetDevices: The connection is closed
gnome-session[17886]: WARNING: App 'gnome-settings-daemon.desktop' respawning too quickly

Looks rather like the gnome-color-manager issue, to me. If you boot with the kernel parameter 'enforcing=0' does it work? Can you paste the output of 'ls -lZ ~/.local/share/icc'? Thanks.

$ ls -lZ ~/.local/share/icc
-rw-rw-r--. amit amit unconfined_u:object_r:data_home_t:s0 edid-aedae9cc758035a92e98b5122d91dfec.icc

I also have the following in my kernel log:

[  150.092297] type=1400 audit(1319992063.856:7): avc:  denied  { read } for  pid=746 comm="dbus-daemon" path="/home/amit/.local/share/icc/edid-aedae9cc758035a92e98b5122d91dfec.icc" dev=sda6 ino=136474269 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file
[  150.093254] type=1400 audit(1319992063.857:8): avc:  denied  { read } for  pid=1214 comm="colord" path="/home/amit/.local/share/icc/edid-aedae9cc758035a92e98b5122d91dfec.icc" dev=sda6 ino=136474269 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file
[  150.129243] type=1400 audit(1319992063.893:9): avc:  denied  { getattr } for  pid=1210 comm="colord" path="/home/amit/.local/share/icc/edid-aedae9cc758035a92e98b5122d91dfec.icc" dev=sda6 ino=136474269 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file

so yes, looks like the gnome-color-manager issue; I'll put this info on that bug.

(Sorry, didn't mean to hijack this bug, but this looked the closest to my issue of all the other 'Oh no' bugs)

amit: don't really need any more info, I know all about that problem; we're just going to have to document it, until someone fixes g-s-d. To solve the problem, just do restorecon -vr ~/.local/share .



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

See also bug 708968, bug 735311, bug 737037, bug 746476.

I experienced the same issue after upgrading from F15 to F16 through yum (yesterday), then rebooting (today).  No matter how many times I tried, it wouldn't log into the Gnome session — although my delayed conky screen appeared on top of the "something has gone wrong" screen…

In order to isolate the problem I first moved every hidden directory of my /home/user to a backup directory, then I tried to log again and it worked.  Then I tried to find which directory was the problematic one by replacing the new directories by the old ones and relogging until I could not log in again.  Unfortunately I couldn't reproduce the issue anymore.  Then I removed all the new directories and copied the content of the backup directory to /home/user, so it should have been an exact copy of when it failed, apart from the modification time.  Oddly enough, again the issue didn't appear anymore, so I can't give any information about why it failed at first.  All I can tell is that at first I removed the following directory and it didn't help : .dbus, .gconf, .gconfd, .gnome2.

(Yes, I've read the comment about not needing more info, but it seemed weird enough to me to be noted.)

Oh, and I believe priority and severity of this bug should be increased — no offense, but I find it hard to believe that a bug which prevents the user to login after an upgrade is up since several weeks and hasn't been fixed before an official release…

skippy: what you're describing is clearly not the same as either of the two different issues that were reported in this bug, so please don't further hijack this report.

closing this one as the OP had an issue with caribou which was likely just a typical mirror sync arch snafu.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** Bug 753397 has been marked as a duplicate of this bug. ***

I'm re-opening this for the case of the caribou package with the wrong arch getting installed, which seems to be happening to quite a few people, though I haven't managed to figure out why yet. Anyway, we should have a bug to document this.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** This bug has been marked as a duplicate of bug 753149 ***

I ju moved from Ubuntu to Fedora 16 and got the same error.
I tryed to solve my problem with Elad Alfassa instructions
rpm -q caribou
rpm -e --nodeps
install the x86_64 version.
But I get the same error.
I get a message, it says that gnome-shell-3.2.1-2.fc16.i686 needs caribou (x86-32) but it installs caribou (x86-64).
How to solve it?

you should have actually removed caribou using command
yum remove caribou.i686

This command will try to remove all dependent i686 packages on your x86_64 system. Once above command successfully removes caribou.i686, you need to use following command
yum install caribou.x86_64

If you have already removed caribou.i686 then try following 
yum remove gnome-shell.i686

(In reply to comment #28)
> you should have actually removed caribou using command
> yum remove caribou.i686
> 
> This command will try to remove all dependent i686 packages on your x86_64
> system. Once above command successfully removes caribou.i686, you need to use
> following command
> yum install caribou.x86_64
> 
> If you have already removed caribou.i686 then try following 
> yum remove gnome-shell.i686

I followed your instructions, I removed gnome-shell and caribou then reinstalled them and got the same result.
My kernel says my laptop is i686 and when I try to install caribou.x86_64
a message says that there's no such file.

jose: it does not sound like you have the same bug. you have a 32-bit Fedora install. whatever problem you're having, it is not this bug.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers