Hello, Johannes! Johannes Winkelmann schrieb:
On Mon, Apr 21, 2008 at 17:45:50 +0200, Clemens Koller wrote:
That's what I did: I have an sshd running on a remote machine. And I am logged in to that machine via ssh. Then, I did a prt-get update udev.
A kill and restart of the udevd could have been sufficient, but I decided to execute /sbin/start_udev which mounts the /dev tmpfs and copies initial device files to /dev/
Well... everything in /dev looks fine afterwards, but now if I try to login to the machine via ssh, ssh complains with a nasty "Server refused to allocate pty"
Have you (re-)mounted /dev/pts?
Good hint! The problem is indeed this missing mount. It is easy to reproduce: $ killall udevd $ start_udev ssh doesn't work now, the nested mount /dev/pts devpts in mtab isn't properly updated (cleared) when the /dev tmpfs is mounted again even if $ mount ... devpts on /dev/pts type devpts (rw) ... shows (because it's only a dump of maps) that devpts is mounted, but it's not: $ mount -n -t devpts -o remount,rw pts /dev/pts mount: /dev/pts not mounted already, or bad option Whereas $ mount -n -t devpts pts /dev/pts works and ssh is happy. And again: $ mount -n -t devpts pts /dev/pts mount: pts already mounted or /dev/pts busy mount: according to mtab, devpts is already mounted on /dev/pts So, the mtab entry doesn't reflect the actual mounts after start_udev. $ cat /proc/mounts doensn't tell the truth, either. :-( After playing around with all this, /proc/mounts contains several duplicate entries. Hmm... is there a way to see what's really currently mounted in the system and which mounts are really "valid"? Regards, Clemens