Boot hangs at "starting udev"

Discussion in 'General' started by markrmcs, May 13, 2008.

  1. markrmcs

    Joined:
    May 8, 2008
    Messages:
    3
    Likes Received:
    0
    I have searched and searched for a fix to this issue to no avail.

    I am using a Supermicro SuperServer 6010H dual 1MHz processor with 1024MB RAM with a Digium TDM2400 w/ 12 FXS/12 FXO installed.

    full specs of the server here:

    http://www.supermicro.com/products/syst ... -6010H.cfm


    linux-tested.com claims that this server is 100% linux compatible, see here:

    http://www.linux-tested.com/results/smi ... _1ghz.html


    Elastix appeared to install ok.

    When I boot it always hangs at "Starting udev"

    This is a "hard hang" -- I have to do a power cycle to recover.

    I have searched the CentOS forums and it was suggested to append acpi=off noapic to the kernel line...no joy...

    This issue is present with the Xen kernel or normal kernel. I have booted successfully with the install disc after passing the linux rescue option. When the device is running in rescue I removed all of the rules in /etc/udev/rules.d and attempted a reboot. This boot was ultimately successful but I imagine that not all devices are running??

    I am not sure how to get around the issue of the udev hang with the rules in place. If anybody can give me guidance as to where to proceed to resolve this issue it would be appreciated.

    Thanks in advance for any help/pointers/nudges in the right direction anyone can give me
     
  2. markrmcs

    Joined:
    May 8, 2008
    Messages:
    3
    Likes Received:
    0
    After much hair pulling and consultation with others I have solved this problem and am posting what I did as an aid to other people that have the same or similar problem...

    Initially I thought that the boot was hanging at "Starting udev". This in fact was not the case. udev was successfully starting and it was hanging at whatever was happening after /sbin/start_udev was called.

    Searching for solutions showed, that at least in CentOS, /sbin/start_udev was called in rc.sysinit.

    I found that in /etc/rc.sysint just after /sbin/start_udev was called the modules under /etc/sysconfig/modules/*.modules were called with the following:


    -------------------------------------------------

    # Load other user-defined modules
    for file in /etc/sysconfig/modules/*.modules ; do
    [ -x $file ] && $file
    done

    -------------------------------------------------


    So I looked in /etc/sysconfig/modules/ directory The only *.modules were:


    -------------------------------------------------

    udev-stw.modules

    -------------------------------------------------


    This file contains:


    -------------------------------------------------

    #!/bin/sh
    for i in nvram floppy parport lp snd-powermac;do
    modprobe $i >/dev/null 2>&1
    done

    -------------------------------------------------


    I am not in any shape or form a bash expert but it appears to me that the system tries to load each of these modules and dumps any messages returned to the "bit bucket" due to the ">/dev/null 2>&1" portion of the script.

    I commented the portion of rc.sysinit that called this script and rebooted.

    After that, from the command line, I attempted to load each of the modules in turn. the nvram and snd-powermac modules returned errors that they could not be found. The floppy and parport modules loaded without incident. The lp module caused a "hard" system hang, i.e. system, keyboard, etc. totally unresponsive requiring a power cycle reset. This leads me to believe that it is the lp module that is causing the boot "hang" problem.


    Further research seemed to indicate that this module (lp) appears to control printing to the parallel port. Since I will not be doing any printing from this system, especially via the parallel port, I un-commented the parts of /etc/rc.sysinit that called this *.modules file and then removed the lp module call from the udev-stw.modules file and booted without incident.


    Hope this helps anyone with this problem.


    Mark
     

Share This Page