Description of problem: Updated a machine that was running F17 to F20 beta. X fails to start now. The following stack trace snippet seems to be the issue. [ 487.120] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error [ 487.121] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error [ 487.121] (EE) Fatal server error: [ 487.121] (EE) xf86CloseConsole: VT_ACTIVATE failed: Input/output error [ 487.121] (EE) [ 487.121] (EE) Please consult the Fedora Project support at http://wiki.x.org for help. [ 487.121] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 487.121] (EE) [ 487.121] (EE) [ 487.121] (EE) Backtrace: [ 487.124] (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x4734f9] [ 487.124] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7fe4a328374f] [ 487.125] (EE) 2: ? (?+0x0) [0x51] [ 487.125] (EE) [ 487.125] (EE) Segmentation fault at address 0x51 [ 487.125] (EE) FatalError re-entered, aborting [ 487.125] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 487.125] (EE) How reproducible: Always.
Created attachment 823049 [details] Xorg log
Proposed as a Blocker for 20-final by Fedora user gnat using the blocker tracking app because: Its a regression from previous versions of Fedora.
"Its a regression from previous versions of Fedora." That alone does not justify blocker status. Single-system hardware-related bugs are not generally taken as blockers, FWIW. The log you've given isn't much use as-is; if anything, from that, I'd guess you've got hardware issues - a segfault in libpthread and some mysterious Input/output errors sure look like that kind of thing. You might want to look in / attach journalctl / dmesg as well.
tested in VirtualBox F20 spin fedora-live-Scientific-KDE_x86_64 beta rc5 as install worked fine
what DM you running and dmesg would be good.
(In reply to Dave Airlie from comment #5) > what DM you running and dmesg would be good. F20 spin fedora-live-Scientific-KDE_x86_64 beta rc5 So KDE not sure how to retrieve dmesg
I'm running Gnome. I'll load dmesg for you soon.
satellit: we don't need anything from you in this bug unless you're actually hitting a crash. We need info from the original reporter.
Created attachment 823233 [details] dmesg
One other piece of information. I found a similar bug that was affecting lots of different hardware, though those with ati/radeon said that removing the xorg-x11-drv-glamor or something like that fixed the issue. I tried it here but it didn't work. So that xorg log is without xorg-x11-glamor and xorg-x11-drv-ati installed. Let me know if you need/want them re-installed.
So I've gone and installed MATE Desktop, and then did a telinit 5. X comes up with a login prompt... Not sure if installing MATE pulled in a bunch of updates or not. I'll see what happens if I uninstall MATE and have only GNOME installed.
so even though I installed MATE when I logged in it was GNOME... very curious. I'll report back when I know more.
Why would that be curious? Just installing a desktop doesn't magically mean you'll log in to it the next time. You have to pick it explicitly from the session list in your login manager.
Well more so I find it curious that X doesn't even start, no GDM nothing. I get a terminal login screen. I install the MATE desktop environment and the login screen I get does not look like the GNOME one I get from my two other F20 machines. So its curious to me that installing another desktop environment fixes the entire issue even though I was seeing a Xorg crash. So is this bug really a GDM issue maybe? I just wouldn't expect installing MATE to suddenly get X working that's all.
can you attach an X log and dmesg now the problem's been 'fixed' so we can compare?
Discussed in 2013-11-14 Blocker Review Meeting [1]. This was voted as a RejectedBlocker. This doesn't seem to be a general issue, but affect only the reporter. If this turns out to be an issue affecting large portion of our user base, please re-propose. Also try to run clean F20 environment from LiveCD and report back. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-14/
Created attachment 824580 [details] xorg log from working system I'm wondering if the issue was that on upgrade there was some missing package gdm needed/needs. Since installing MATE the login screen is not GDM. In the other bug that had a somewhat similar stacktrace they mentioned that the Color whatever function in there is somewhat of a catch all during crashes. If gdm crashed and caused that issue I wonder if xorg isn't the actual proper target for this bug.
I am also getting a similar issue, X reporting a fatal server error, with the following: [ 2229.872] (II) evdev: Video Bus: Close [ 2229.872] (II) UnloadModule: "evdev" [ 2229.872] (II) evdev: Power Button: Close [ 2229.873] (II) UnloadModule: "evdev" [ 2230.164] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error [ 2230.164] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error [ 2230.165] (EE) Fatal server error: [ 2230.165] (EE) xf86CloseConsole: VT_ACTIVATE failed: Input/output error [ 2230.165] (EE) [ 2230.165] (EE) will attach dmesg and full X.org.0.log as well as the abrt direectory (I notice both a kernel crash as well as the x-server crash here), this is with only gnome installed using the default (non-sping) installation media, also similar to the original submitter, this was a direct fedup upgrade from up-to-date F17 to F20 (performed yesterday 11.29.2013). Will then also try installing MATE desktop to see if that resolves the issue here as well...
Created attachment 830723 [details] Multiple logs for X crash issue
so after yum install mate* I can now successfully run startx after the system boots, but I still get exactly the same crash if I let X try to start via systemd, similarly a systemd stop graphical, systemd start graphical results in the same result, no running X server, and only text console login capabilities
interestingly, after installing and using switchdesk utility I now get a graphical login, and no more X server crashes.. One thing that might be a clue, when I ran switchdesk from within Gnome (started via startx) i was presented with the install/anaconda adduser page...re-entered ny existing user details, and presto, graphical login, even after a reboot...
Faced the exact same issue with exact same trace upgrading from fedora 17 to 20. I have onboard Intel graphics.
I get exactly the same error ( /usr/bin/X (OsLookupColor+0x129)) when starting chrome or chrome-unstable on F19 (fglrx).
I've just seen mine is a bit more verbose, here it is: [ 2523.168] (EE) [ 2523.168] (EE) Backtrace: [ 2523.168] (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x46f059] [ 2523.169] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7fd38704ef9f] [ 2523.169] (EE) 2: /lib64/libc.so.6 (____strtod_l_internal+0x74) [0x7fd385c8dca4] [ 2523.169] (EE) 3: /usr/lib64/xorg/modules/extensions/catalyst/libglx.so (GlxInitVisuals2D+0x24782) [0x7fd382938c22] [ 2523.169] (EE) 4: /usr/lib64/xorg/modules/extensions/catalyst/libglx.so (__glXSetTexBufferInfo+0x1fd7) [0x7fd3828f1027] [ 2523.170] (EE) 5: /usr/bin/X (SendErrorToClient+0x3f7) [0x437217] [ 2523.170] (EE) 6: /usr/bin/X (_init+0x3aa2) [0x429db2] [ 2523.170] (EE) 7: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fd385c71b45] [ 2523.170] (EE) 8: /usr/bin/X (_start+0x29) [0x426a21] [ 2523.170] (EE) 9: ? (?+0x29) [0x29] [ 2523.170] (EE) [ 2523.170] (EE) Segmentation fault at address 0x0
Digging a bit further it looks like OsLookupColor is somewhat a catchall for errors related to X11. Sorry for the spam.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.