Update of udev needs reboot?
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
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
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
participants (2)
-
Clemens Koller -
Johannes Winkelmann