Hi There!

After a lenghtly holiday I am now back to update some of
my servers. Please note that an update of udev from 117 to 120
could be dangerous if you cannot access the machine physically.

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"

Even if the proper device nodes are present, the sshd still
references to the old ones and therefore cannot allocate
new ptys?
I also tried to restart sshd without improvement. The above
message still denies any logins.

So, it seems like the machine really needs a reboot in that
case to recover proper udev managed /dev ?
Is there any way to update udev safely without the need for
a reboot?
I recommend to _not_ update udev in that case.

Feedback is welcome.

Regards,

Clemens
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux

Hi Clemens,

On Mon, Apr 21, 2008 at 17:45:50 +0200, Clemens Koller wrote:
> Hi There!
>
> After a lenghtly holiday I am now back to update some of
> my servers. Please note that an update of udev from 117 to 120
> could be dangerous if you cannot access the machine physically.
>
> 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?

Johannes
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux

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
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux