Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Blacklist udev from yum, prevent PTY errors

  1. #1
    Join Date
    Jun 2006
    Posts
    74

    Default Blacklist udev from yum, prevent PTY errors

    OpenVZ and udev are not compatible. Udev is apparently not able to populate /dev properly during the boot sequence under openvz. The OS templates provided by VPSLink have udev disabled and the devices created statically.
    If you install/update udev by accident on your server (e.g. with yum) it will be re-enabled again and /dev will be corrupted, locking you out your VPS.
    Once this happens your only options are to open a trouble ticket, or to reinstall your server from the control panel.

    You can prevent this by adding the following lines to /etc/rc.local:
    Code:
    /bin/rm -rf /dev/null
    /bin/rm -rf /dev/random
    /bin/rm -rf /dev/tty*
    /bin/rm -rf /dev/pty*
    /bin/mknod /dev/null c 1 3
    /bin/mknod /dev/random c 1 8
    /sbin/MAKEDEV tty
    /sbin/MAKEDEV pty
    It will force all the devices needed for a ssh connection to be created each time your VPS boots.
    Last edited by Pierre_@_VPSLink; 08-06-2007 at 06:52 PM. Reason: shorter and clearer post

  2. #2
    Join Date
    May 2006
    Location
    GMT +10
    Posts
    375

    Default

    Another good option would be for VPSLink to include these tweaks into their OpenVZ templates for CentOS, so the problem won't occur at all - at least on new installs (or re-installs).

  3. #3
    Join Date
    Feb 2006
    Posts
    773

    Default

    It's a very very slippery slope when we start making those changes inside an OS template. Other programs that may depend on udev may not be available for install via yum..and then we're supporting a whole different issue.

  4. #4
    Join Date
    May 2006
    Location
    GMT +10
    Posts
    375

    Default

    Well, maybe point taken re udev.

    But you should certainly consider putting something like the following into yum.conf in the OpenVZ template for CentOS, since it doesn't make sense for it not to be there:

    exclude= kernel*

    It causes users known problems if yum goes and tries to upgrade the kernel under OpenVZ

  5. #5
    Join Date
    Aug 2007
    Location
    Toronto, Ontario
    Posts
    29

    Default

    If you want to help determine what is causing null to be deleted/overwritten, and a more controlled replacement script use this:

    Code:
    #!/bin/sh
    /sbin/MAKEDEV tty
    /sbin/MAKEDEV pty
    
    #if random devices/files do not exists as character-special file
    if [ ! -c /dev/random ]
    then
            rm -f /dev/random
            mknod -m 644 /dev/random c 1 8
    fi
    if [ ! -c /dev/urandom ]
    then
            rm -f /dev/urandom
            mknod -m 644 /dev/urandom c 1 9
    fi
    
    #check to ensure null device is correct as well
    if [ ! -c /dev/null ]
    then
            FNAME=`date --date "today" +"null-%Y-%m-%d_%H.%M.old"`
            cp -f /dev/null /root/$FNAME
            rm -f /dev/null
            mknod -m 666 /dev/null c 1 3
    fi
    Then add this to rc.local or some other script that runs on startup.

  6. #6

    Default

    I realize that this sticky is fairly old, but it is a sticky and I've been wondering if it is still applicable with CentOS 5.x (or even other versions)....

    Since it doesn't look like there was a clear-cut decision made either way -- and I don't know nearly enough about Linux to make an educated decision about it whatsoever -- I was wondering if someone could clarify this a bit more?

    It appears to be a very severe issue (at least in theory, maybe I've been lucky so far with YUM updates, as I haven't had a problem...yet). And again, just since it is a sticky posted (and debated) by VPSlink admins, it would be very helpful to hear if this is still something that we need to be worried about and/or take appropriate steps to prevent a potentially severe outcome if we accidentally update.

    ...or if it (hopefully) isn't an issue anymore -- maybe it could be "demoted" from the magic-Sticky-status, just so it doesn't keep us newbies awake at night
    Thanks yet again for everyone's help.

  7. #7
    Join Date
    Jan 2006
    Posts
    127

    Default

    Hello,

    Yes, this is still applicable. Our template developers have modified yum.conf in our published templates (RPM based distributions) and have taken some proactive measures to try to ensure the /dev entries are created when a VPS boots up, but since we give full root access, you are still able to remove our customization of yum.conf and hit this problem. (The most common result of this problem is inability to log in via SSH, "Server refused to allocate a pty" or "Connection refused.")

    To clarify/simplify:
    1) Don't install udev unless you know you really need it.
    2) If you do install it, add the lines Pierre_@_VPSLink recommended at beginning of this thread to /etc/rc.local (or some other script that runs on startup) to ensure those device files exist.

  8. #8

    Default

    Lyle,

    Ok, thanks a ton for the advice. Glad I didn't run into this before (luck I guess?), because I'd have had no idea of how to fix it

    I just checked my rc.local file, and the only thing it currently has in it is:

    touch /var/lock/subsys/local

    And, when I do a "yum update", it does show an UPDATE for udev [so I guess I already have it installed? I'm using the CentOS/Hib/Lxadmin template...

    So before I actually do the yum update, should I for sure add all of those lines to my rc.local file as mentioned in the 1st post? Just because I was lucky before, doesn't mean I will be after the update from yum I'm guessing....I think you answered this in your last reply, but if you don't mind and have time, I just wanted to double-confirm

    Thanks again.

  9. #9

    Wink

    I didn't receive the double-scary-nerve-settling reply
    So I went ahead and did it...and it's all working fine

    As mentioned in this thread, I added the said lines to the file at "/etc/rc.local"
    Actually on mine, that was a symbolic link --> "/etc/rc.d/rc.local" [I think that was it, going from memory here, but something like that].
    So if anyone tries, I would say to make sure you're not overwriting the alias to the real file and/or just make sure it's the correct spot...as I don't know enough to know why that alias is there instead of the real file -- but at least that's how mine is setup.

    Anyways, yes it works so far. I'm pretty sure udev got updated when I did the "yum update", and things still seem to work as before here...so either I'm lucky once again, or this trick worked and saved weeks of my life stressing over trying to fix it after accidentally updating udev

    So thanks again everyone in this thread, I appreciate all of the help and direct, simple instructions on how to fix it.

  10. #10
    Join Date
    Oct 2006
    Posts
    13

    Default

    Looks like this is still required should udev slip into your setup.

    As appears in Marcusone's post you have to make sure to setup /dev/null as user writable or you'll get some chaff.

    Code:
    /bin/rm -rf /dev/null
    /bin/rm -rf /dev/random
    /bin/rm -rf /dev/tty*
    /bin/rm -rf /dev/pty*
    /bin/mknod -m 666 /dev/null c 1 3
    /bin/mknod /dev/random c 1 8
    /sbin/MAKEDEV tty
    /sbin/MAKEDEV pty
    My VPS was re-setup this Feb/March with the latest CentOS image. As my VPS is shared with several admins, I can't be 100% positive. However, looking through my yum.conf file I don't see any excludes. In yum.log, I also see kernel and udev packages getting updated in the very first "yum update".

    Are these exclusions in the base image at all? Should they be?
    Last edited by DavidOrser; 05-17-2011 at 07:17 PM.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •