Mike,
Here is the solution. Apparently this is a particular problem with
slackware 10.0...
http://www.pocketace.net/pocketace.php?pg=articles&ar=slackware)
(excerpt)
"The Slackware udev.rules included with Slackware 10 needs to be altered
for the man, less and ssh commands to work properly. To fix this problem
you need to edit the /etc/udev/rules.d/udev.rules file. The change is in
the pty devices section, you need to change
KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k" to read
KERNEL="tty[p-za-e][0-9a-f]*", NAME="pty/s%n", SYMLINK="%k". Thats it
just change the t to a p, and everything should work."
Bryan
On Thu, 2006-04-20 at 09:32 -0700, Mike Ireton wrote:
Bryan,
This problem also drove me absolutely bonkers once also, and what
the deal was had to do with the fact that the 'console' device was
invalid. There is some interaction which I still to this day don't fully
understand, between ssh and /dev/console. This stuff the list is
suggesting regarding /dev/tty* is in the same vein but only applies if
you're logged in thru ssh already, and I suspect you're on your vga
console.
Would you humor me and do the following?
ls -l /dev/console
cat /proc/cmdline
uname -a
Also, your ttys all do look funky as the list noted. Have you tred:
cd /dev
./MAKEDEV tty
(MAKEDEV is the standard script which populates /dev with device
entries)
Also, is devfsd running perchance?
Mike-
Christ, Bryan wrote:
Yes. I am completely at a loss. The Linux kernel version I updated to
is 2.6.15.3. After chmoding 666 on /dev/tty, I changed it back to 777
because it is definitely a directory. Evidence below:
root@gateway:/dev/tty# ls -l
total 0
crw------- 1 root root 3, 10 2007-03-21 00:58 s
crw------- 1 root root 3, 0 2007-03-21 00:58 s0
crw------- 1 root root 3, 1 2007-03-21 00:58 s1
crw------- 1 root root 3, 2 2007-03-21 00:58 s2
crw------- 1 root root 3, 3 2007-03-21 00:58 s3
crw------- 1 root root 3, 4 2007-03-21 00:58 s4
crw------- 1 root root 3, 5 2007-03-21 00:58 s5
crw------- 1 root root 3, 6 2007-03-21 00:58 s6
crw------- 1 root root 3, 7 2007-03-21 00:58 s7
crw------- 1 root root 3, 8 2007-03-21 00:58 s8
crw------- 1 root root 3, 9 2007-03-21 00:58 s9
On Wed, 2006-04-19 at 08:11 -0400, Greg Wooledge wrote:
On Tue, Apr 18, 2006 at 09:58:24AM -0500, Christ, Bryan wrote:
Most of the suggestions I have read say to chmod 666 /dev/tty, but
my /dev/tty is a directory.
That's bad. That's very, very bad. I'd suggest you get in touch with
one of the support forums (mailing lists, IRC channels, etc.) for your
operating system.
ssh bryanc@192.168.0.103
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-with-mic,password).
If you did indeed issue "chmod 666" on a directory, that might explain
part of the problem -- a directory which lacks the "execute" bit would
be untraversable.
debug1: read_passphrase: can't open /dev/tty: Is a directory
debug3: packet_send2: adding 8 (len 51 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
Permission denied, please try again.
*nod* Whatever your Linux distribution has done, fixing it is probably
outside the scope of this mailing list. /dev/tty is supposed to be a
character device node. Shell scripts and other Unix programs have *always*
been able to count on "read foo < /dev/tty" working. If /dev/tty is a
directory, that will break a *lot* of stuff.
I'm hesitant to suggest even something as simple as "man MAKEDEV", for
fear that any attempt to fix this snafu (without understanding the
primary cause) will just make it worse.
