Bug 741075 - Oh no! Something has gone wrong at GDM after upgrading from F15 to F16 x86_64, caused by wrong arch of caribou package
Summary: Oh no! Something has gone wrong at GDM after upgrading from F15 to F16 x86_64...
Keywords:
Status: CLOSED DUPLICATE of bug 753149
Alias: None
Product: Fedora
Classification: Fedora
Component: caribou
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Parag Nemade
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 753397 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-24 23:55 UTC by Matias Kreder
Modified: 2011-11-22 13:25 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-18 05:03:56 UTC


Attachments (Terms of Use)
messages with debug while loading GDM (68.39 KB, application/octet-stream)
2011-09-25 00:08 UTC, Matias Kreder
no flags Details
messages with debug while loading GNOME (17.85 KB, application/octet-stream)
2011-09-25 00:10 UTC, Matias Kreder
no flags Details
.xsession-errors (22.70 KB, text/plain)
2011-10-29 14:45 UTC, Amit Shah
no flags Details

Description Matias Kreder 2011-09-24 23:55:08 UTC
Description of problem:

After upgrade to F16 beta from F15. GDM is not able to start.
This is not a duplicate of bug 735252 as SELinux is currently disabled on my system and the issue is still present.

Version-Release number of selected component (if applicable):

gdm-3.1.90-1.fc16.x86_64
gnome-shell-3.1.91-2.fc16.x86_64

How reproducible:
Always in mi case

Steps to Reproduce:
1. Upgrade from Fedora 15 to F16 Beta
2. Wait for GDM to appear
  
Actual results:

GDM displays a famous error message.

Expected results:

GDM working.

Additional info:

I'm attaching the output of messages with debug while restarting GDM with CTRL + ALT + BACKSPACE

Comment 1 Matias Kreder 2011-09-25 00:08:08 UTC
Created attachment 524759 [details]
messages with debug while loading GDM

Comment 2 Matias Kreder 2011-09-25 00:09:50 UTC
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

Comment 3 Matias Kreder 2011-09-25 00:10:22 UTC
Created attachment 524760 [details]
messages with debug while loading GNOME

Comment 4 Elad Alfassa 2011-09-25 04:48:31 UTC
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.

Comment 5 Matias Kreder 2011-09-25 15:03:02 UTC
Elad, thanks that is a workaround for my GDM problem. GNOME problem still persist. I will open a separate bug for it.

Comment 6 Matias Kreder 2011-09-25 16:48:52 UTC
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.

Comment 7 Amit Shah 2011-10-17 12:48:09 UTC
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.

Comment 8 Victor Rehorst 2011-10-18 16:07:48 UTC
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.

Comment 9 Amit Shah 2011-10-29 04:43:36 UTC
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?

Comment 10 Adam Williamson 2011-10-29 04:50:08 UTC
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

Comment 11 Adam Williamson 2011-10-29 05:31:50 UTC
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

Comment 12 Adam Williamson 2011-10-29 05:42:07 UTC
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.

Comment 13 Matias Kreder 2011-10-29 12:19:23 UTC
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.

Comment 14 Amit Shah 2011-10-29 14:45:37 UTC
Created attachment 530783 [details]
.xsession-errors

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

Comment 15 Adam Williamson 2011-10-29 17:12:22 UTC
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

Comment 16 Adam Williamson 2011-10-29 17:13:56 UTC
_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.

Comment 17 Amit Shah 2011-10-30 17:35:17 UTC
$ 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)

Comment 18 Adam Williamson 2011-10-30 17:45:41 UTC
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

Comment 19 Skippy 2011-11-10 22:18:30 UTC
See also bug 708968, bug 735311, bug 737037, bug 746476.

Comment 20 Skippy 2011-11-10 22:39:12 UTC
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.)

Comment 21 Skippy 2011-11-10 22:43:28 UTC
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…

Comment 22 Adam Williamson 2011-11-10 23:10:08 UTC
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

Comment 23 James Begley 2011-11-12 08:55:47 UTC
*** Bug 753397 has been marked as a duplicate of this bug. ***

Comment 24 Adam Williamson 2011-11-17 21:56:05 UTC
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

Comment 25 Adam Williamson 2011-11-18 03:35:23 UTC

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

Comment 26 Parag Nemade 2011-11-18 05:03:56 UTC

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

Comment 27 Jose Alayo 2011-11-21 03:47:33 UTC
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?

Comment 28 Parag Nemade 2011-11-21 04:04:02 UTC
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

Comment 29 Jose Alayo 2011-11-21 21:12:01 UTC
(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.

Comment 30 Adam Williamson 2011-11-21 23:45:25 UTC
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


Note You need to log in before you can comment on or make changes to this bug.