Red Hat Bugzilla – Bug 68030
startx from run level 3 fails if a window manager is specified in .Xclients
Last modified: 2007-04-18 12:43:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
Description of problem:
specifying a window manager such as twm, sawfish, etc. in the ~/.Xclients file
brings up either a blank screen or a screen with vertical stripes covering the
entire screen when startx is used from run level 3; same setup works fine from
run level 5
gnome starts up fine from run level 3 with startx if there is no .Xclients file
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. choose run level 3
2. create ~/.Xclients file with "exec windowmanager" for some window manager
3. login and enter startx
Actual Results: screen fills with vertical strips
Ctrl-Alt-Backspace is the only way (other than reset button) to get
out; no mouse cursor, etc.
Expected Results: appropriate window manager should start from run level 3
I use run level 3 since I enter my ssh passphrase and use ssh-agent before
starting X so the passphrase doesn't need to be retyped in each terminal window
Riva 128 video card
Almost certainly an X server bug.
What video card?
Attaching your /etc/X11/XF86Config-4 and the output of startx
(startx > /tmp/log 2>&1) will also probably be helpful.
While I suppose it's possible it's an X server bug, I wonder why the window
managers start fine when it's already at run level 5?
The video card is a Riva 128 - I believe it's an NVidia card prior to the TNT
cards - my brother gave it to me a couple years ago. It did work when Red Hat
7.2 and 7.3 were installed on the machine and it does currently work in run
level 5. This is my "test machine" so it's got some old parts. My "main machine"
has a Radeon 7500, but I'm not ready to try the beta on my "production" machine.
There's only an XF86Config (not a XF86Config-4 file), although rpm -qa|grep
XFree seems to indicate only XFree 4 is installed.
I'm attaching the "XF86Config" file, the "log" file from running the startx
command, and the XFree86.0.log file.
Have any of you tried running startx from run level 3 and specifying a window
manager in your ~/.Xclients file (twm or sawfish produce similar problems)?
Created attachment 63854 [details]
Created attachment 63855 [details]
Created attachment 63856 [details]
startx > /tmp/log 2>&1
I think fvwm2 may actually be running even though there are just stripes. If I
press the keyboard accelerators to change workspaces, the stripes do change colors
so maybe it is running and different workspaces have different stripes.
And sometimes I see the inital cross-hatch (that IIRC X starts with) for a few
seconds before the stripes. I've got the line: xsetroot -solid "#000000"
in my .Xclients so each workspace should be all black.
Use ~/.xinitrc instead.
~/.xinitrc is a symlink to ~/.Xclients
I did: rm .xinitrc; mv .Xclients .xinitrc
but that didn't change anything.
The log file attached is that of a working session. I need the log file
from a session which does not work.
The second log file seems to show that your .xinitrc might be misconfigured.
I'm beginning to think Owen is correct - it must be a video driver issue.
My .xinitrc is very plain. I've even tried it with just:
and it still doesn't work.
This whole bug report doesn't make a lot of sense to me.
Either the video driver works or doesn't work. The window manager
doesn't enter into it. I've no idea what could be causing the problem
you're seeing, but it doesn't occur with any cards I try locally.
I do not have Nvidia hardware supported by the "nv" driver. Someone
who has this hardware will need to debug the issue to see what is
happening that is causing this problem.
It's really not a big deal to me since this is my "test" machine; my main machine
has a Radeon 7500 which the next official release will be installed on. If there's
anything I can do that's not too much work, I'm willing to try but I don't want
to spend a lot of time on it since this is old hardware that very few people
I've seen this several times with my Geforce2 card. It seems that the card isn't
initialized properly. A workaround for me was to switch to a different
resolution witch Ctr-Alt-<keypad +> and back to the original resolution.
Does this work for you ? (You need to have at least 2 different modes configured
I installed the new beta (null) and when I first typed startx, I just got a blank
screen with the x cross-hair cursor. I then hit ctrl-alt-<keypad +> and then the
windowm manager took over and worked.
Thanks for the workaround.
Please try the latest developmental XFree86 CVS packages from:
Do the new XFree86 packages solve this problem for you?
The new packages don't help. I still need to cycle through the sizes using
ctrl-alt-<keypad +> before it looks ok. It's definitely something with the
nv driver. I finally got around to installing 8.0 on my laptop and everything
is fine there with the same setup (except it has an ATI video chipset).
This definitely seems to be an 'nv' driver bug. If the problem still
exists in current generation Fedora Core 2 test2 or later with
X.org X11, please report the issue upstream via:
http://bugs.freedesktop.org against the 'xorg' component, and
paste the upstream bug URL here for us to track the upstream
driver maintainer's resolution. There's not really a lot we can
do for 'nv' driver related bugs other than get the reporter to
test if disabling acceleration solves the issue and then hard
code in the driver to disable acceleration, or to do finer
grain testing with XaaNo options (as per XF86Config manpage) and
disable just the flawed primative.
In this case however, it seems that the EnterVT/LeaveVT code is
probably not setting up the card or restoring it properly, and
doing a VTswitch flips something in to place. Someone with
physical access to this hardware, and the databooks would need
to investigate it to fix, which is probably only possible via
Closing as WONTFIX.