l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2002 Jun 28 17:45

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Re: Part Way Into X
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Re: Part Way Into X



I hope this does not come off as arguementative. In the very least, you
(Ken) are asking some good questions and helping to add new ideas to help
solve this. I cannot encourage you enough to continue raising more
questions as they include good observations. Sometimes adding a fresh
perspective can really help the process. Please do not let this
"emotionless analytical styled response" make you think I am being mean or
unkind.

On Fri, 28 Jun 2002, Ken Bloom wrote:
> I think you missed something. He said the pattern he saw on his monitor
> was moving, and that is *definitely* not normal. I speculate that he
> doesn't have a ~/.xinitrc or a ~/.xsession, and so he has gotten the
> checkerboarded default X screen, with an xterm in the upper-left corner.
> (see `man xinit`)

The box was black though, not white.  The default xterm started is a white
box with black letters. There were diagonal lines of various colors much
like th "qix" screen saver leaves. This was consistent with the reports I
found with the "screensaver bug". However, the other line that would pass
vertically over 3 seconds from top to bottom also X server problems.

Though inversion of color pallette or improper user of pallette can make
colors not appear as we expect, there are too many things int he
description that conflict with any single one of "screen saver" "X-config
settings" "libs added" "libs changed"or your good idea to include,
"default X Server settings with xinit/startx" (and this is a good
suggestion to include! :-). More is pointing to harware issues, and
repatability in this case is so far lacking which hurts our ability to
diagnose it better.

> Because of a misconfiguration in his XF86Config or his XF86Config-4, his
> monitors scan is not synchronized with his monitor signal, hence we get
> a scrolling rainbowish mess of the scene that he should be seeing which
> I described above.

Running against this are the claims the XF86 config file has not been
altered since X was last working, and no alterations have been made to
packages since it was last running.

Running for this would be if X did not come back after the reboot. (Still
waiting to see confirmation to the question I posed asking for an explicit
answer on X working after reboot instead of relying upon an implicit
direction that it was running.)

If X was working before and is not working now and none of the config or
support libs have changed, where can the problem reside? (This is the
difficult tech support question - one that goes from not working to
working with no apparrent changes.) The last report sounded like he
rebooted the machine and it was back up and running and he was back in
"X". Nothing changed between the boot immediately before where it was
frozen to now. Puzzling to say the least. ( :-/   )

> As for the ctrl-alt-backspace problem he described, I don't know what
> causes it, but I do know that when the RedHat 7.1 machines in the ECS
> labs are functioning *properly* they don't allow ctrl-alt-backspace, and
> so I can't use ctrl-alt-backspace to log out users that have
> disappeared, leaving their computers logged-in and locked.

keymapping can change how keys work, but how would they come to be without
the default ~/.x scripts and those in /etc that would leave the machine to
not have a window manager either.

Control-Alt-Backspace no work, and control-alt-f1 no work. As I read from
Peter and the guy reporting the problem, X was started from a command
line. Should control-alt-f1 still work even if the above is the case even
if control-alt-backspace did not? (I dont know RedHat so well. This is a
genuine question not stated in sarcasim or being condescending. It would
be good to know as I try to help others.) Also, if you are not running in
a window manager and no ~/.xinitrc (etc) and it was the case that an xterm
was on the desktop with no mods to alter keys etc to prevent
control-alt-backspace from killing X, then there is a contradiction of
sorts. (more puzzling)

Also, the machine became non-responsive to pings. That should not be a
function of a poor display but actually one of a halted machine. However,
this assumes it could be pinged before X was started.

> The problem with the FTP server I am at a loss to explain.

Also contributes to pointing to the problem being a halted kernel -
possibly caused by an X server bringing the system down with it.

Saving the log file may help to diagnose a future incident. If it happens
again with his alteration to disable the screensaver, we can eliminate at
least one possible item from our list of problems.

We can also examine heat, uptime, and reliability of the HD in case swap
was being used excessively and something was corrupted.

Of course, we need another event like this and I am sure the owner does
not want another event like this. ]:>

-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html

> > --- ORIGINAL MESSAGE ---
> > Reply-To: vox-tech@lists.lugod.org
> > 
> > hi jim,
> > 
> > believe it or not, in a sense, nothing is obviously wrong.  X is prolly
> > working just fine.
> > 
> > for whatever reason, you're not running a window manager or desktop
> > manager.  this is what X looks like when she's completely naked and
> > exposed.
> > 
> > i'm not familiar enough with redhat to know how to get your previous
> > configuration back.  there are many different ways to get a win manager
> > and/or desktop manager running.
> > 
> > in the meantime, to kill it, just do ctl-alt-backspace as usual.
> > 
> > what does your $HOME/.xinitrc contain?
> > 
> > what does your $HOME/.Xsession contain?
> > 
> > what happened recently that might have changed your system?
> > 
> > send me the contents of startx 2>filetosendpete
> > 
> > hth,
> > pete
> > 
> > 
> > begin Jim Angstadt <jimajima9@yahoo.com> 
> > > Hi All,
> > > 
> > > [I'm re-sending this.  I used on old address before.]
> > > 
> > > My Red Hat 7.1 box booted normally to the command line
> > > this morning.  Ran startx and hung part way into it. 
> > > I see a carpet pattern that slowly moves N to S and is
> > > composed of diagonal lines in various colors.
> > > 
> > > How do I get out of limbo?  Please keep it simple.
> > > 
> > > ---
> > > Jim
> > 
> > -- 
> > Isn't it funny that our president is ok with having every inbred yahoo
> > armed to the teeth but is against arming our pilots with even a stun gun?

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.