udev problems

Bryan Kadzban bryan at kadzban.is-a-geek.net
Wed May 26 17:50:39 PDT 2004


Bryan Kadzban wrote:
> Anyway, I think I should do some testing.
> 

All right.  I passed init=/bin/bash to the kernel.  I then mounted /proc
so that ps would work, and ps aux reported that udevd was already
running.  It had a PID of 140, while the ps process itself had a PID of
142.  mount was obviously 141.  So wherever it's coming from, it's the
last process started before the shell is given control.

Inspecting /proc/140/environ (on a whim) showed that DEVPATH was set to
/class/vc/vcsa1 (the device used to get access to the virtual console's
memory with attribute support), and SEQNUM was set to 129.  I am
assuming that DEVPATH was inherited from the udevsend call that the
kernel made.

The sequence number seems to indicate that this hotplug event was
generated late in the kernel's initialization (and the PID indicates
that it was probably last; if it wasn't last, then the last hotplug
invocation would have gotten PID 141, mount would have gotten 142, and
ps would have gotten 143).

It isn't framebuffer console related, because the same thing happens
whether I boot with vga=794 (my default) or with no vga= argument at
all.

It might be how udev gets set up -- I assume you have a symlink to
udevsend at /etc/hotplug.d/default/udev.hotplug, right?

You aren't using the initrd approach, right?  It doesn't look like the
/lfs/view/unstable/ book does this, so I assume not (I am not using it
either).

Which kernel?  This is 2.6.6 (yes, even with the annoying IDE spindown
on reboot issue).



More information about the lfs-dev mailing list