I can't say for sure, but maybe you have a bad harddrive, or harddrive
controller?
I got my old 486 (a packard hell, no less) up and running without any
problem using Slackware 7. And with Slackware, you don't have to install
anything for X.
On Fri, 17 Mar 2000, Lighthouse Keeper in the Desert
First, I would like to thank everyone who answered my earlier question. You were most
helpful :)
Second, under Slackware 4, I was able to use ifconfig to configure multiple IP
addresses for one NIC. eth0:1, eth0:2, etc. However, I have upgraded to Slackware 7
and can no longer accomplish this.
The following lines show up on a ps -eaf | more
root 218 1 0 11:38 tty2 00:00:00 /sbin/agetty 38400 tty2 linux
root 219 1 0 11:38 tty3 00:00:00 /sbin/agetty 38400 tty3 linux
root 220 1 0 11:38 tty4 00:00:00 /sbin/agetty 38400 tty4 linux
root 221
I tried the DISPLAY variable since it seemed the simplest solution, and it
worked. :) I had logged out of X before I left the machine, but echo
$DISPLAY still existed. When I cleared that, I could use vim
remotely while su to other users.
Thanks!
On Fri, 3 Dec 1999, Laurel Fan wrote:
> Excerp
Thank you, I am looking into that. :) I was in the middle of replying to
the first message when yours came in. I didn't mean to seem as if I was
ignoring you.
On Fri, 3 Dec 1999, Maureen Lecuona wrote:
> I will try again.
>
> You are having a problem most likely with an .Xauthority file under
ctions[1] can
> only be made by authorized users. For example (if paxumbrae is the
> remote and hermes is the local, and lilith is your username on both),
> when you make the ssh connection from hermes to paxumbrae, the ssh
> client assumes that you, lilith@hermes, will allow X connecti
Hi. :)
I am currently running Slackware 7.0 with vim 5.5
I am encountering an odd error that when I am remotely connected to my
computer and su to another user (any user, including root), I get the
following error message:
X11 connection rejected because of wrong authentication at Fri Dec 3
Couldn't you use hosts.deny to deny all telnet/ssh/etc access to the
machine, then explicitely allow yourself or anyone else you'd like to have
it through hosts.allow?
If no one is to get shell access on that machine, you could simply not
load the telnet daemon if you have ready access to the ma
