Bug 46218

Summary:	startx and Xwrapper problem and solution
Product:	[Retired] Red Hat Linux	Reporter:	Chris Bitmead <chris>
Component:	XFree86	Assignee:	Mike A. Harris <mharris>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.1	CC:	rbrown
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-02-09 15:50:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Bitmead 2001-06-27 13:16:04 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18)
Gecko/20001123

Description of problem:
I can't see how startx ever could have worked in RH7.0,
nevertheless, this is what it took to get it working for me.
Change line 33 in startx to say server= instead of serverargs=
Otherwise the args end up in the wrong order down the bottom
with display coming before the server which is wrong. Then
X must be a symlink to the specific X server I am using
(i.e. not a link to Xwrapper.). Then there must be a
xserverrc file that execs Xwrapper. The final outcome here
is that startx execs xserverrc which execs Xwrapper which
execs X which is a symlink to my accelerated server.
Having X a symlink to Xwrapper doesn't seem to work because
Xwrapper doesn't know which accel server to start.

How reproducible:
Always

Steps to Reproduce:
1. default RH7.0 startx doesn't start, just hangs.
2.
3.
	

Additional info:

Comment 1 Chris Bitmead 2001-06-27 13:19:48 UTC

When I said RH7.0, I meant RH7.1.

Comment 2 David Lawrence 2001-06-27 13:29:09 UTC

*** Bug 46217 has been marked as a duplicate of this bug. ***

Comment 3 Mike A. Harris 2001-08-16 02:02:13 UTC

startx works fine in all releases of Red Hat Linux.  I use startx
exclusively ever since RHL 5.0, so this bug is totally unreproduceable
by me.  Can you reproduce this on a fresh clean install (not upgrade)?

Comment 4 Chris Bitmead 2001-08-16 02:46:29 UTC

I don't have the facilities to do a clean install.
I have been continuously upgrading since many RH
versions ago. Feel free to close this bug if it
looks like it's going nowhere.

Comment 5 Chris Bitmead 2001-08-16 02:50:18 UTC

However, I would appreciate it if you could clarify exactly how
the Xwrapper stuff is supposed to be setup. I suspect something
somewhere has got screwed up in the RH upgrade path. Is my
setup above correct? I can never actually figure out how Xwrapper
is supposed to figure out which X server to run. The above works,
but I don't think it is how RH comes out of the box.

Comment 6 Mike A. Harris 2002-02-09 15:50:35 UTC

Xwrapper is not supposed to be ever touched by the end user.
Xconfigurator manages the X configuration symlinks automatically.
Doing any configuration by hand is not supported. Always use
Xconfigurator to choose either the 4.x server, or a 3.3.6 server
using the --preferxf3 and --preferxf4 commandline options.  That is
more of a tech support issue though, which bugzilla isn't intended
for.

The startx issue you describe however needs some further looking into.
I'll need to test it out on a clean installation to see what happens.

Comment 7 Mike A. Harris 2002-05-21 03:13:12 UTC

The X server that gets ran, is a symbolic link which is configured by
Xconfigurator.  Closing bug as NOTABUG as it seems to have been just
a local configuration mishap or somesuch.