mdev with USB wifi adapters

Laurent Bercot ska-dietlibc at
Sun May 13 10:16:37 UTC 2012

> 1) Is it possible to determine more info about the device, so that we
> can "write mdev rules"?  I'm talking manufacturer/serial#/etc.

 See for yourself:

# cat /usr/local/bin/printenv-hotplug
exec /usr/bin/printenv > /tmp/hotplug-env

# chmod 755 /usr/local/bin/printenv-hotplug
# echo /usr/local/bin/printenv-hotplug > /proc/sys/kernel/hotplug

 Now plug in a USB device and look at the contents of the
/tmp/hotplug-env file. That's all the information the kernel exports
and that is usable by udev or mdev.

> 2) Is it possible to somehow determine whether the system is booting up,
> or if it has already finished booting, and provide separate rules in
> /etc/mdev.conf?

 No, but you can change /etc/mdev.conf atomically at the end of your
init scripts. Depending on your setup, though, it might be difficult to
ensure the original /etc/mdev.conf is restored for your next boot, even
in the case of a dirty reboot. Better find another workaround.

> I obviously do not want to apply custom rules for USB
> sticks to  my harddrive /dev/sda, which would result in an unbootable
> system.  A heavy-handed approach would be to set up rules for
> (sd[b-z])([0-9]+)
> at the top of /etc/mdev.conf.  In my case I have one built-in drive,
> which shows up as /dev/sda.  It would be skipped by the above rule.

 Just have a single rule for /dev/sd* and have a
  if [ "$DEV" = "/dev/sda" ] ; exit 0
line at the beginning of your rule script. (Maybe $DEV isn't the right
variable name, I don't remember.)

> 3) If 2) above is possible, I may need to invoke scripts, rather than
> one-line commands.  Where would be a good place to put them?  A couple
> of ideas for script directories are /etc/mdev.d/ and /var/lib/mdev/  Is
> this a general thing or would it depend on the distro?

 Totally distro-dependent. As a rule of thumb, I like to be able to
boot even if /var is borked, so I use /etc (on a read-only filesystem)
for boot-time basic scripts and /var/lib for run-time advanced stuff.


More information about the busybox mailing list