From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-6.2.7smp i686; Nav)
Description of problem:
If I attempt to "startx" on a 7.2 install the X server starts but only displays
a grey background (only X is running no gome-session et al). If I change
/etc/X11/xinit/xinitrc to source ('.') /etc/X11/xinit/Xclients rather than exec
Xclients everything works. That is gnome-session starts, sawfish is loaded,
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. watch grey screen
Actual Results: grey screen of core X server is displayed, meaning Xclients is
never exec'd this has been verified with various echo debugging when starting X
Expected Results: /etc/X11/xinit/Xclients should be run and then gnome-session
should be started along with sawfish and the rest of the gnome desktop.
I'm at a loss as to why sourcing /etc/X11/xinit/Xclients fixes the problem
whereas exec of Xclients never actually happens... no X related rpms or files
are being modified. If I run Xconfigurator and test the setup I specified
(while maintaining exec /etc/X11/xinit/Xclients in xinitrc) the test display
starts and works perfectly fine with sawfish, gnome panel, etc running.
After I finish Xconfigurator and type startx the grey X server just sits there;
that is until I ctrl-alt-backspace out of X and change line 72 of
Created attachment 49486 [details]
patch to source Xclients instead of exec
Are you using bash as your login shell, or tcsh or some other shell?
I am using bash as the login shell. btw, Xclients has permissions 755 and has
This bug was reported a long time ago, however I remember investigating
it when I added my initial comment above. At that time, I was
not able to reproduce the problem. I use startx almost exclusively
to start up the X server on all my systems, and I have never
encountered this problem on any OS release. The code in xinitrc
simply exec's the /etc/X11/xinit/Xclients script, which as you've
indicated above is executable.
I'm going to assume that this was a configuration or installation
quirk on your system, as no other user has reported this to us
as a bug, and many people use 'startx' to start the X server, so
the problem must have been isolated to that specific system.
Setting bug state to "WORKSFORME", as this is unreproduceable, and
nobody else seems to have this problem on other systems.