hotplug and modalias handling (WAS: Re: RFD: Rework/extending functionality of mdev)
bitjam at gmail.com
Fri Mar 20 00:02:33 UTC 2015
On Wed, Mar 18, 2015 at 02:48 AM, Isaac Dunham said:
> Is this manifested as "the root device never shows up"?
Yes, although we call it the boot device.
> As the one who probably posted this, I can comment further:
> I've heard of one computer where this was an issue, a couple
> years ago; a number of people on the Puppy Linux forums were
> experimenting with mdev, and one reported that the modalias
> file was missing with a Broadcom wireless card.
That is interesting. Do you think this could have been due to a
bug in the broadcom driver? We don't do any networking in our
initrd/initramfs so maybe we can get by with the faster methods
that use modalias files instead of uevent files. The broken
hotplugging (or whatever the problem is) is a bigger issue for
us now even though it is small compared to the problems caused
by the broken modprobe a year ago.
> However, you may find it worth noting that "find /sys" will get
> its list of files slightly later than globbing will.
I don't know what the globbing solution is that you refer to. It
took me a little while to understand the following solution from
the alpinelinux initrd/initramfs, partly because it does not work
here at all:
find /sys -name modalias | xargs sort -u | xargs modprobe -a
It fails badly whenever one or more modalias files has a space in
the path (which is the case here). That is easily remedied with:
find /sys -name modalias -print0 \
| xargs -0 sort -u \
| xargs modprobe -a -q -b 2>/dev/null
This is probably more efficient than what I'm currently doing
if /sys is replaced with /sys/devices. Thank you.
> Do you wait for the boot device to show up?
Oh yes. It would not work if we didn't.
> I know the kernel has a rootwait parameter for similar issues
> with usb drives.
We stopped using the related "rootdelay" years ago. We try to
find the boot device as quickly as possible. I don't think
rootdelay is applicable unless root= is specified (or something
like that) but even if it were, making users guess how long it's
going to take for the buses to settle (or whatever) seemed overly
crude. We have a fixed timeout of 10 or 15 seconds. We keep
trying to find and mount the boot device until the timeout is
reached. If we can't find it within that time window then we
give up. As long as the correct modules get loaded, this scheme
works well. It tends to boot as quickly as possible without
adding unnecessary delays.
> Of course, the root device may be unknown depending on what
> you're doing, which would make waiting properly rather
We have several different modes. The default mode is to
scan all usb/removable devices and all cdrom/dvd devices,
mounting each in turn, looking for the file(s) we need.
This is repeated until the file is found or the timeout is
reached. You can also specify the boot device with a label
or a uuid (even a partial uuid) or a device name like sdb1.
You can also specify the type of device: cd (includes dvd),
usb (includes non-usb removable devices), or hd (internal
On machines that can't boot directly from usb, the "from=usb"
boot parameter has proved to be popular. The boot starts with a
LiveCD but then uses a compatible usb stick as the boot device
which is faster than the LiveCD and makes other features
available such as persistence and remastering.
> (What I'd be inclined to do is check for the root and if it
> fails, coldplug a second time/blindly load sd_mod and
My latest solution is to coldplug inside the loop that looks for
the boot device. When we were experiencing the bug in the
smaller busybox modprobe about a year ago we tried various
schemes of always loading certain modules but that was not very
satisfactory. It masks the problem instead of fixing it and it.
If loading of hardware specific modules is not 100% reliable then
where do you draw the line of which specific modules to load on
every machine. Likewise, loading a bunch of modules after a
delay can in some cases just further postpone the eventual
ISTM repeated coldplugging is a reasonable compromise even if it
is not as elegant as hotplugging. At least it only loads modules
that correspond to the hardware.
Thank you for your help. This discussion has been useful to
More information about the busybox