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

Dag Wieers dag at wieers.com
Mon Oct 4 13:38:02 CEST 2010

On Sun, 3 Oct 2010, Schlomo Schapiro wrote:

> On 30/09/10 16:35, Dag Wieers wrote:
>> 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:
>        $(
>                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.

I think I was confused. I thought the above logic was used only when udev 
was not available as a fallback. And assumed udev was used for finding all 
currently loaded drivers. I have to say the web of symlinks and 
directories doesn't help in uncovering ReaR's execution flow :-/ I am not 
a big supporter of the current structure :-/

> 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.

Right, I read the comments in the files :-)

> 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.

I agree.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]

More information about the rear-users mailing list