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: > > > >[EMAIL PROTECTED]:/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 [EMAIL PROTECTED] > >>>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. > >> > >> >