Created attachment 702803 [details] strace over the startup attempt containing xinit process events. Description of problem: X server fails early on at bootup, and falls back to text mode The Xlog.0.log doesn't really tell anything to be wrong. I had to try starting once as root (again fail) to collect strace data Version-Release number of selected component (if applicable): xorg-x11-server-common-1.13.2-4.fc18.x86_64 xorg-x11-server-utils-7.5-16.fc18.x86_64 xorg-x11-server-Xorg-1.13.2-4.fc18.x86_64 xorg-x11-xinit-1.3.2-7.fc18.x86_64 libxcb-1.9-1.fc18.x86_64 xcb-util-0.3.8-3.fc18.x86_64 xcb-util-keysyms-0.3.8-4.fc18.x86_64 xorg-x11-drv-nouveau-1.0.6-1.fc18.x86_64 How reproducible: Persistent. Usage of proprietary driver as well as nouveau driver fails the very same way, which seem to indicate that xinit is upset, but I can't decode the X-protocol message xinit received. Steps to Reproduce: My updated installation (from FC17 to FC18). No idea if there is a way to reproduce. Actual results: X server shuts down when xinit sends it SIGTERM. That it sends right after receiving following message from the server. Observe also that the libxcb tries to read more data twice, and then states a claim of connection being lost: poll([{fd=3, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"<\0\2\0\0\0 \0+\1\1\0", 12}, {NULL, 0}, {"", 0}], 3) = 12 poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}]) recvfrom(3, "\1\0\n\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0, NULL, NULL) = 32 recvfrom(3, 0x1d34484, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(3, 0x1d34484, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) write(2, "xinit: ", 7) = 7 write(2, "connection to X server lost", 27) = 27 write(2, "\n", 1) = 1 kill(4294964385, SIGHUP) = 0 kill(4294964388, SIGTERM) = 0 wait4(2908, 0x604ba0, WNOHANG, NULL) = 0 write(2, "\r\nwaiting for X server to shut d"..., 36) = 36 Additional info: AMD Phenom(tm) II X4 965 Processor (fam: 10, model: 04, stepping: 03) 02:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device 2610 systemd configured to boot to TEXT console, and from there I execute explicit manual "startx&" command.
Created attachment 702804 [details] strace of X-server
The issue turned out to be that xinit utility is way too quiet about why it decides to shut down the system. I modified the xinit code in debug package, and compiled it again. Then I got to see that: "child process started with argv: ...." "server process started with argv: ...." "child existed with code: ..." "shutting down the X server process." and it became a lot easier to locate what was wrong - namely that at some point the yum has erase my kde-workspace package. I also added setvbuf(stdout,_IONBF); setvbuf(stderr,_IONBF); to help to see in what sequence things really are happening.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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.
The issue is still present at F19, and probably also at soon to be upgraded to F20.
Hi Nadav, I'm the new xorg-x11-"apps" maintainer. First of all sorry that this bug has been sitting still for so long. unfortunately the graphics team always seems to have more bugs then we can deal with. I've taken a (quick) look at the issue your describing here. If I do: startx /bin/doesnotexist I get: xinit: Unable to run program "/bin/doesnotexist": No such file or directory Which seems fine to me. If the program actually executes, then it is up to the program executed to print error messages if something goes wrong IMHO. Regards, Hans
As for the summary: "xinit isn't telling WHY it shuts down the X server" xinit always shuts down the X server as soon as the program it is executing as the primary X client (e.g. a session or window-manager) exits. As said in my previous comment the problem is said program not explaining why it is exiting if it is exiting due to an error instead of a normal logout / end of session.