Bug#217068: acknowledged by developer (Re: Bug#217068: xserver-xfree86: X won't run, unknown reason)
On Wed, 22 Oct 2003, Debian Bug Tracking System wrote:
> It has been closed by one of the developers, namely
> Branden Robinson <branden@debian.org>.
>
> Their explanation is attached below. If this explanation is
> unsatisfactory and you have not received a better one in a separate
> message then please contact the developer, by replying to this email.
> > [Update, I have now gotten X to run from kdm (gdm still dies).
> > Tale of the story below. I don't know if you want to adjust
> > the severity level as things now run, but without reconfiguring
> > X and switching from gdm to kdm I would still not be running.
> > Whatever the problem is, mozilla/galeon is now broken. ]
>
> You no longer have an X problem. Even if you had, the severity of this
> report would have been inflated. Please file bugs at normal severity
> and trust the package maintainer(s) to upgrade it to the appropriate
> severity. (Only if xserver-xfree86 didn't work for anyone would the
> "grave" severity be appropriate.)
When people file bug reports, they commonly only have their own
experiences to work from. If you guys do not want us to file
grave reports, perhaps you should remove that choice from what
reportbug gives us. Looking at the descriptions of the various
levels provided, grave seemed the most appropriate.
If I felt I no longer had a problem, I wouldn't have filed a bug
report. The steps I went through were not things that I thought
most people would use in trying to track down a problem.
> > The first possibility I looked at, was that the last error showing in
> > the logs or ~/.xsession-errors dealt with /dev/input/mice. Since I
> > don't have a USB mouse, I first tried creating /dev/input and making
> > mice a symlink to /dev/ttyS0 (I should have used /dev/psaux in after
> > thought).
>
> This probably was not a necessary thing to do and I would revert it.
> Fatal errors are generally described as such in the server output.
This whole episode has been plagued by a lack of any kind of
output. It was reverted shortly after. I was just documenting
how I was trying to go through what output I could find, in order
to try and figure out what the problem was.
> > There were also messages about some missing symbols in=20
> > libGLcore.a and libspeedo.a.
>
> Also completely harmless.
Is this fact documented somewhere? If so, I missed it.
> > X still wouldn't start. I then edited ~/.gnome2/gdm so that it
> > wouldn't use "Debian" (KDE) as the window manager. This didn't help.
> > I then started editing /etc/X11/XF86Config-4 (as you can see below).
> > I started by editing out the font path to speedo, and the modules load
> > stuff for speedo and GLcore. Trying to startx again, I got another
> > error which led me to trying to also comment out glx, leaving me at
> > the config you see below. This still doesn't work.
>
> I wouldn't have expected them to. You seem to have been shooting in the
> dark. The folks on the debian-user mailing list can probably help you
> with troubleshooting in the future.
Shooting in the dark. I was getting messages in log files and
.xsession-errors files, having to do with what looked like XFree86
misconfiguration. How is trying to correct this misconfiguration
shooting in the dark?
> > I have known for a while, that the management of the configuration
> > for X has changed in Debian (to what it has now). I don't remember
> > as to whether there were any minor problems in the transition. After
> > the first edit to /etc/X11/XF86Config-4, I followed the instructions
> > at the top of the file vis a vis saving a custom configuration.
>
> Okay. Given that you have the X server itself working again, I'm
> guessing there weren't any actual problems here.
Who knows? I am certainly not happy with how I "solved" (hacked
would be a better description) the problem. If I knew what was
wrong in the first place, I probably could have done a better job
in trying to track down what to change/fix. But nothing shows up
in the logs or on stderr.
> > I am getting a DeprecationWarning about xreadlines when I do this
> > (dpkg-reconfigure xserver-xfree86) followed by a configlet in path
> > is bad.
>
> That's a Python error, and neither xserver-xfree86's configuration
> script nor debconf are written in Python.
Fine. How does a python script get run when I dpkg-reconfigure
your package, if nothing uses python?
> > Other people in my lug have suggested things. Some kind of problem with
> > libfreetype6 conflicting with gsfonts-other. I've looked in bug reports
> > for xserver-xfree86, libfreetype6, gsfonts-other and see nothing which
> > really looks similar to this problem, with a recent time frame. Well,
> > there is one report, which was closed because a virus was found in a
> > followup message?
>
> That probably has something to do with your problem. That a piece of
> spam closed a bug report should not be taken as evidence that a bug was
> actually resolved, by the way.
That one bug report, which seemed to have something in common with
what I was seeing, only had the single entry to it, followed by
this spam/virus thing that seems to have closed the report. There
was nothing to follow. No comment by the developer, nothing.
> > I'll try reconfiguring all of X (xserver-xfree86) with xf86cfg and then
> > purging gsfonts-other, and after that installing older versions of
> > xserver-xfree86. If you have suggestions as to how to trace things
> > (as I am not receiving error messages now, but it still won't start)
> > or where the problem lies, I'ld be happy to hear them.
>
> In the future, I'd rule out X client problems first of all.
If I had X running before trying the reconfigure route, I would
have been happy to. But unfortunately I don't know how to rule
out an xclient problem if X itself won't run.
> As, root, simply run the command "X". If that brings up the little root
> window weave and the X cursor, then *you do not have a fatal X server
> configuration problem*. The X server is working. Use
> CTRL-ALT-BACKSPACE to kill it.
I was using startx (or trying to). It wouldn't work. Looking at
the shell script that is /usr/bin/X11/startx, I don't see how just
running X all by itself would have been any better.
> Alternatively, if you're using a display manager and you can see the
> greeter (login screen), then the X server is running: *you do not have a
> fatal X server configuration problem*. Most failures after that point
> are client-side problems. (Yes, there are bugs in the X server that can
> cause it spontaneously crash, but if the X server "crashes" immediately
> upon logging in to your X session, it's probably a client side problem.)
The very first time after the apt-get of stuff, I had a greeter.
It probably started to run client side stuff. Which was why I
edited ~/.gnome2/gdm to have it NOT try to start the same WM it
had been trying to run. But that first crash (or 4 crashes in a
row, followed by dialog (whiptail?, not curses) box asking me if I
wanted to quit having gdm try to start things) was different than
every attempt after that. All of those attempts had no greeter.
X would try to start and then die. If I was trying to start X via
gdm, I got the 4 or 5 crashes followed by the dialog box. If I
tried startx, it was only a single attempt.
> > Running xf86cfg (after moving /etc/X11/XF86Config-4 aside),
>
> Oh boy. Is your bug report deliberately a litany of things NOT to do?
Your bedside manner leaves a lot to be desired as well. I am not
a GUI programmer, but I have been programming for about 20 years.
And whenever I've had the good fortune to get some kind of email
from you as the result of a bug report, you always try to make me
feel like a baby that hasn't a clue what is going on. Why don't
you write up a trouble shooting giude for the applications you
package and include it in the docs of stuff you package. So that
we can follow your obviously much better methods.
> > I went
> > through the configuration process, setting values to what they should be
> > for keyboard, mouse, card and monitor. When I go to save things, it
> > asks if I want to write /usr/X11R6/lib/X11/XF86Config. I can't say I've
> > seen that location for a X config file before. :-) Okay, change it
> > to /etc/X11/XF86Config-4. Now it wants to write a keyboard config
> > file to lib/X11/xkb/X0-config.keyboard. No idea what the leading
> > directory is, and my system never had a X0-config.keyboard file before.
> > /etc/X11/xkb doesn't contain any files like this, nor does it seem
> > to be the place to put this. And there is no /etc/X11/lib. Since
> > /usr/X11R6/lib/X11/xkb seems to be a symlink to /etc/X11/xkb, I guess
> > I can let it write this file and see if PWD is pointing to /usr/X11R6.
>
> This is why people shouldn't use xf86cfg, and why I continue to suspect
> I shouldn't even ship it. I thought I documented the fact that people
> should use the debconf interface to configure the X server, but I guess
> that message doesn't come through loud enough.
I assumed that if debconf had screwed it up in the first place
(the configuration file), and I had tried to fix things via
dpkg-reconfigure and things were still screwed up, that I should
try something that had nothing to do with debconf. Maybe it could
generate a configuration file that would work to the point that I
could then get a proper error someplace (stderr, log file, I
didn't care).
If debconf was perfect, I would say go ahead and remove xf86cfg.
Certainly xf86cfg has characteristics which seem to be at odds
with how Debian operates. This surprised me, which is in large
part why I documented them. I guess I wasted my time.
> > gdm still won't start X (tries 4 times and quits). Nothing strange
> > (besides the Skipping ... messages) in XFree86.0.log or gdm/:0.log.
> > Editing /etc/init.d/kdm to change the HEED_DEFAULT_DISPLAY_MANAGER
> > to false, I find that kdm will work, and both X and KDE seem to start
> > okay.
>
> Sounds like there is a problem in gdm or one of the libraries it uses.
> I think the person in your LUG was probably right about you getting bit
> by the latest bug in libfreetype6. You might have saved yourself some
> time if you'd been a little more critical when reading that report; a
> piece of spam marking a bug as done is not legitimate usage of the
> Debian BTS, and tells us nothing about the status of the underlying
> defect.
There was nothing in that report. Just the existance of a
problem.
> Closing this spurious report. Thanks for taking the time to write all
> of this up anyway. It gives me food for thought as to the desperate
> means some users will attempt when they're convinced something is the X
> server's fault (despite evidence to the contrary, even...).
Write that troubleshooting guide. I was not trying to insult you
or anyone at Debian in writing my report, but I sure hate getting
feedback that tries to say that I am incompetent.
Gord
Reply to: