Update of udev needs reboot?

Clemens Koller clemens.ml at gmx.net
Mon Apr 21 20:20:57 UTC 2008


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



More information about the CRUX mailing list