Waiting for /dev to be fully populated...

Kernels, Network, and Services configuration
Post Reply
Message
Author
VelvetLicks
Posts: 5
Joined: 2013-01-21 20:09

Waiting for /dev to be fully populated...

#1 Post by VelvetLicks »

Hi all,

As this post title explains, I'm still waiting!
The storu ran as following:
- Attached a new USB Flash Drive to my Asus Laptop.
- Installed Wheezy onto this new device
- Test this installation (works pretty well)
- Add few applications & deamons (Jackd, Ardour, Rosegarden...), stille working as it's supposed to

In order to be able to run Ardour (v2.x), I should install an rt kernel, using Aptitude I checked its avaliable in Wheezy depots... Yes it is!

- Install it, update-grub, reboot...
- rt kernel ias 1rst choice, std kernel second
- choose 1
- As expected I got:
Loading, please wait...
Init: version 2.88 booting
Using makefile-style concurrent boot in run level S
Starting the hotplug events dispatcher udevd
Synthesizing the initial hotplug events... done
Waiting for /dev/to be fully populated...

Unfortunatly, this wait never ends!

- Reboot, choose 2, here I am telling you the story ;-)

Any idea to solve this issue? Please don't tell me to install Ubuntu-Studio and/or Tango Studio or whatever but a pure Debian!

VelvetLicks

VelvetLicks
Posts: 5
Joined: 2013-01-21 20:09

Re: Waiting for /dev to be fully populated...

#2 Post by VelvetLicks »

Well,
I've reconfigured Grub for having a verbose boot process...
Populating /dev freezes at:
ETPS/2 Elantech Touchpad as /device/platform/i8042/srio4/imput/input10.

uname -a returns : Linux BlueVelvet 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux
The rt kernel I would be able to use as been install onto same /boot after:
- runing:
apt-cache search linux-image
linux-headers-3.2.0-4-amd64 - Header files for Linux 3.2.0-4-amd64
linux-headers-3.2.0-4-rt-amd64 - Header files for Linux 3.2.0-4-rt-amd64
linux-image-3.2.0-4-amd64 - Linux 3.2 for 64-bit PCs
linux-image-3.2.0-4-amd64-dbg - Debugging symbols for Linux 3.2.0-4-amd64
linux-image-3.2.0-4-rt-amd64 - Linux 3.2 for 64-bit PCs, PREEMPT_RT
linux-image-3.2.0-4-rt-amd64-dbg - Debugging symbols for Linux 3.2.0-4-rt-amd64
linux-image-2.6-amd64 - Linux for 64-bit PCs (dummy package)
linux-image-amd64 - Linux for 64-bit PCs (meta-package)
linux-image-rt-amd64 - Linux for 64-bit PCs (meta-package), PREEMPT_RT

- then:
apt-get install linux-image-rt-amd64

This last command ends with no warning, no error.
Booting with the non rt kernel my touchpad works perfectly...
Is there any way to tell the kernel to not use the pad?
Is there any firmware (free or non-free from backports or from wherever) I should install?

Please help me, googling return no answer at the moment ,-)

VL

phiberoptik192
Posts: 1
Joined: 2013-08-07 23:50

Re: Waiting for /dev to be fully populated...

#3 Post by phiberoptik192 »

Yep, having the exact same problem.

Well, not sure if I'm getting caught up on the touchpad, but I am stuck at the "waiting for /dev to be fully populated" prompt.

I booted into recovery mode and I'm stuck at:
5.167470 fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver

I can't boot Wheezy normally or in recovery... HELP!

User avatar
BoDiddley
Posts: 137
Joined: 2011-08-29 00:39

Re: Waiting for /dev to be fully populated...

#4 Post by BoDiddley »

I had the same problem, but did not die. Just rebooted many times until the one time it passed by that message "waiting for dev to be populated". This only began with wheezy for me as well.

After very exhaustive research someone mentioned that this message is almost always connected to wireless. I am wired, I do not use my onboard wireless. Even when I need wireless I use usb adapter, not onboard. Therefore....

I searched this file "/etc/udev/rules.d/70-persistent-net.rules" and found that my wireless was being enabled at every boot. So I commented-out the b43 line. You could verify that everything in this file is actually useful for your system.

Now the only time I hang on "waiting for /dev to be populated" is after running Bleachbit, and after a full system virus scan. It hangs on the first reboot, no more.

I do not think you are down completely, keep rebooting.
"Wisdom is justified of all her children."

MBianchi
Posts: 2
Joined: 2012-05-30 15:46
Location: New Jersey

Re: Waiting for /dev to be fully populated... [SOLVED]

#5 Post by MBianchi »

I feel like I have _almost_ found the ANSWER. It only took a week.
3.2.0-4-amd64 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux

See the attached udev.modified file. My modifications are near the comments that start #MMMMMMMMM .

I'ved tried to attach a file, but it has not showed up yet. Sigh.

The problem comes about because the udevadm trigger command causes actions on the various buses, in particular the PCI and PCIexpress buses that hold things like the graphics cards. And in particular the graphics card that is being written to by the /etc/init.d/udev script that is running the udevadm trigger command. In my case, this produced a (supposedly) harmless message saying that the pcieport driver was not able to do something it wanted to.

But that is the problem. The graphics card is being touched _while_ the udev script is trying to write through it.
In my case, the boot would fail about once every 5 times or so, apparently at random.
But I found, the more log_*_msg items I put in to trace the execution, the more often it failed.

So my modification is to not print anything between the udevadm trigger and the udevadm settle commands.

(I am discovering in further testing that this modification is well shy of 100% reliable. I am still fiddling. The evidence is that the
udevadm trigger is bit fragile when it is poking on the PCI/PCIe bus.

There are also 3 sleep commands in there to avoid a race conditions that apparently exist between and among the log messages and the udevadm commands.

Code: Select all

    ##  This has bee rewritten to prevent writing to the console while
    ##  udevd is populating /dev.
    ##  Experience shows that if the graphics card is being prodded at
    ##  the same time as something is writing to it, the machine might
    ##  suffer a hangup.
    log_action_msg "Populate /dev; wait until it is full. (up to 120 seconds)"

        ##  Yes, the sleeps seem to be necessary.
    sleep 1

    udevadm trigger --action=add

    sleep 2

    udevadm settle

    sleep 2
    log_action_msg "/dev is populated."
Here is the entire start) case (the 2nd one! -- there are two start-stop-restart ... cases in this file)

Code: Select all

# When modifying this script, do not forget that between the time that the
# new /dev has been mounted and udevadm trigger has been run there will be
# no /dev/null. This also means that you cannot use the "&" shell command.

log_warning_msg "$0 $1:  MODIFIED"              #MMMMMMMMMMMMMMMMMMMMMMMMMMMMM

case "$1" in
    start)
    if init_is_upstart 2>/dev/null; then
        exit 1
    fi
    if mountpoint -q $udev_root/; then
        TMPFS_MOUNTED=1
    elif [ -e "$udev_root/.udev/" ]; then
        log_warning_msg ".udev/ already exists on the static $udev_root"
    fi

    if [ ! -e "$udev_root/.udev/" -a ! -e "/run/udev/" ]; then
        warn_if_interactive
    fi

    echo > /sys/kernel/uevent_helper

    move_udev_database

    if [ -z "$TMPFS_MOUNTED" ]; then
        unmount_devpts
        mount_tmpfs
        [ -d /proc/1 ] || mount -n /proc
    fi

    # clean up parts of the database created by the initramfs udev
    udevadm info --cleanup-db

    # set the SELinux context for devices created in the initramfs
    [ -x /sbin/restorecon ] && /sbin/restorecon -R /dev

    # /dev/null must be created before udevd is started
    /lib/udev/create_static_nodes || true

    log_daemon_msg "Starting the hotplug events dispatcher" "udevd"
    if udevd --daemon; then
        log_end_msg $?
    else
        log_warning_msg $?
        log_warning_msg "Waiting 15 seconds and trying to continue anyway"
        sleep 15
    fi

    /lib/udev/write_dev_root_rule

#MMMMMMMMMMMMMMMMMvvvvvvvvvvvvvvvvvvv   Reworked.

    create_dev_makedev

        ##  This has bee rewritten to prevent writing to the console while
        ##  udevd is populating /dev.
        ##  Experience shows that if the graphics card is being prodded at
        ##  the same time as something is writing to it, the machine might
        ##  suffer a hangup.
    log_action_msg "Populate /dev; wait until it is full. (up to 120 seconds)"

        ##  Yes, the sleeps seem to be necessary.
    sleep 1

    udevadm trigger --action=add

    sleep 2

    udevadm settle

    sleep 2
    log_action_msg "/dev is populated."

#MMMMMMMMMMMMMMMMM^^^^^^^^^^^^^^^^^^^^
    ;;

roody15
Posts: 1
Joined: 2014-03-07 15:03

Re: Waiting for /dev to be fully populated...

#6 Post by roody15 »

Simple press "e" at grub boot menu.

Find the boot linux line that ends with quiet and add nomodeset

This will bypass the noveau drivers which is most likely causing your machine to hang at /dev

User avatar
BoDiddley
Posts: 137
Joined: 2011-08-29 00:39

Re: Waiting for /dev to be fully populated...

#7 Post by BoDiddley »

nomodeset seems to impact graphics, based on the little research I have done. This is not a graphics problem.
"Wisdom is justified of all her children."

crc64Error
Posts: 1
Joined: 2014-09-05 15:06

Re: Waiting for /dev to be fully populated...

#8 Post by crc64Error »

roody15, I can not thank you enough for this. Trying to get this 7 year old computer going as a server, and this was exactly the answer I needed.
roody15 wrote:Simple press "e" at grub boot menu.

Find the boot linux line that ends with quiet and add nomodeset

This will bypass the noveau drivers which is most likely causing your machine to hang at /dev

Post Reply