[Rear-users] P2V and including modules in the initrd

Schlomo Schapiro schlomo at schapiro.org
Sun Oct 3 23:22:51 CEST 2010


Hi,

On 30/09/10 16:35, Dag Wieers wrote:
> Hi,
> 
> Currently ReaR uses udev to create a list of modules it requires for 
> its initrd in order to restore (possibly using the network). This works 
> fine if you are restoring to exactly the same hardware, but as soon as you 
> are restoring to different hardware, it's possible your drivers are not 
> part of the initrd, and restoring fails.

Do we really talk about the same thing here? My point of view is that we collect
ALL storage and network drivers into the initrd, see
rescue/GNU/Linux/23_storage_and_network_modules.sh:

STORAGE_DRIVERS=(
        $(
                find /lib/modules/$(uname
-r)/kernel/driver[s]/{block,firewire,ide,ata,md,message,scsi,usb/storage,virtio,xen}
-type f -name \*.ko -printf "%f\n" | \
                sed -e 's/^\(.*\)\.ko/\1/'
                #  ^^^^- remove the .ko, faster one sed call than many basename
calls or shell code
        )
)

which is merged into MODULES later on. If there are drivers that are missing
then it would be a bug with this piece of code, please submit a patch with the
missing subdirectories.

The reason to use udev to load the modules is that apparently that is what the
Linux distributions are doing. They use an udev rule on the modalias attribute
to load suitable modules, which I abstracted to this generic form:

ACTION=="add", ATTRS{modalias}=="?*", RUN+="/bin/modprobe -v $attr{modalias}"

see build/GNU/Linux/60_verify_and_adjust_udev.sh for details (and it cost me
several hours to get that to work on all distros with udev >=0.5 or so !!).

There is an IMHO very important reason why we did it this way in 1.9 and not the
old way (load what is loaded before): The order of loading drivers. This is
probably a really painful part of Linux because AFAIK there is no really perfect
solution to this. AFAIKT most distros load the modules in the order given by the
hardware enumeration (e.g. PCI devices etc.) as seen by udev. previously we
where loading the modules in the order given by lsmod and this lead to problems
for some people, especially with the cursed sata ports which could be ide or
scsi depending on the drivers you load and in which order and depending on the
BIOS setup and how the stars are standing.

After switching to load drivers via udev all this apparently got much much
better, at least with all the cases I could test (mostly the different NICs and
IDE/SATA controllers I can plug into VMware and VirtualBox).

I belief also that nowadays the most appropriate way to influence driver <->
device mapping is with udev rules. So again, by copying them over we stay as
close as possible to the original source system.


> 
> So we really prefer that all modules are part of the initrd, even if this 
> is not always necessary. (Yes, in a disaster you don't want this to be an 
> issue ;-))

I agree that in case of a disaster it should "just work". But I would really
like to load the drivers the "proper" way which IMHO is the same that the
distros are doing. If there are drivers that are not loaded automatically with
our magic udev rule then I would assume that some modalias info is missing in
the module and prefer adding more udev rules to match the PCI/USB/XX IDs to the
module (and we know that then we probably have a risk of loading this driver out
of order).

> 
> So, would it be acceptable to drop the udev-logic and replace it by a much 
> more simple include all storage and network drivers and their 
> dependencies ? Might get you an initrd that is 40MB larger though.

IMHO this would be a step back, I would prefer that we improve the udev-based
driver loading till it is perfect. If the distros start some new magic about
driver loading then I would like us to copy that as well.

Kind regards,
Schlomo

PS: Could you please be more (= really really) specific about the driver loading
problems you had? Including comparing the modinfo output of the correct module
compared with an udev trace (why was there no modalias to trigger it?) and if
the module is missing, tracing why the code above did not take it?

PPS: The above code should be smarter and also take the modules from all kind of
update dirs in /lib/modules/$(uname -r) like dkms and kmod and whatever... But
OTOH they probably are already part of the lsmod list which we still take in any
case.




More information about the rear-users mailing list