[rhelv6-list] module load order changed in initramfs

neo3 matrix neo3matrix at gmail.com
Mon Jan 17 06:31:31 UTC 2011


Hi,
sorry for late reply.

Thank you Jon and everybody for valuable advice.
@Jon: Now I will try to work on the suggestions given by you. Thank You.



On Wed, Jan 12, 2011 at 5:51 PM, Jon Masters <jcm at redhat.com> wrote:

> On Wed, 2011-01-12 at 12:28 +0530, neo3 matrix wrote:
>
> > Thanks for  reply.
>
> No problem. Could I ask that you preserve standard mail formatting
> convention by including a quoting character of some kind (in this case,
> I've used one ">" to indicate your message, and ">>" to indicate your
> quoting of my message, following standard convention. Gmail can do this
> for you, and in fact will do so in the default configuration.
>
> > > You don't :) Not directly. It requires the initramfs to actually be
> > > run and for the module loading to take place in reaction to the
> > > kernel detecting various devices.
>
> > Ok... So I understood that unlike RHEL5, I cannot get drivers and
> > their load order just by digging initramfs
>
> RHEL5 generates a static initrd that contains a module load order. If
> you add new hardware, and so forth, you need to rebuild the initrd
> because it is static. It's simple, and convenient, but it's not as
> flexible as RHEL6. RHEL6 uses a dynamic initramfs that contains many
> possible modules that might be loaded, and scripts that load them. It
> should be possible to use the same initramfs on other machines
> (depending upon the configuration of the "dracut" tool, whether in host
> only mode or not), and is much improved in many other ways.
>
> > > Yea, there is a reasonable expectation that it will be identical
> > > across same boots of the same system, running the same kernel build.
> >
> > Yes, I am restoring the client image on same system, same hardware and
> > using same kernel build.
>
> In this case, why not use the initramfs that was supplied?
>
> > So, I can easily get the drivers and their load orders as listed
> > above, which I used to save and pass it to the client while restoring
> > the client using min os.
>
> Sounds like you're using a totally different "mini distribution" of your
> own to do the restoration, and choosing the modules to load based upon
> those loaded in RHEL. btw, this only works if you are using a similar
> kernel, because if you're not, there's no guarantee that the modules
> will be the same, work the same way, or have the same dependencies.
>
> > This I cannot do with RHEL6 initramfs as their is no provision of
> > getting drivers and their load order from initramfs on RHEl6.
> >
> > So, how can I get such type of  drivers and their sequence specific to
> > RHEL6?
>
> There are two possibilities:
>
> 1). (what I would do) Have your "mini OS" ship with an array of drivers,
> using a standard udev-based load environment, and let it load the
> appropriate drivers automatically, like RHEL-6 does.
>
> 2). Extract the list of modules included in the initramfs for RHEL6 and
> include all of those in your mini-OS. Load them as in "1", using udev.
> You could write a minimal alternative wherein you include all of these
> modules, then generate a modules.dep/modules.dep.bin and repeatedly call
> "modprobe -b" with the module alias detected from running various tools
> (again udev is the proper solution, but there are potential hacks).
>
> Taking the list from the running RHEL-6 system, before problems arise,
> as you say you are thinking about doing, will not be sufficient, unless
> you do it on every boot of the system (and even then), because there is
> no guarantee that additional drivers will not be loaded onto the system,
> that the hardware won't be changed between boots, or that the kernel was
> not upgraded to one that loaded a new or different module after reboot
> (this would occur between minor releases of the RHEL-6 product).
>
> I hope this helps. If you need further assistance, I suggest contacting
> our GSS (support) and filing a ticket, or GES (consultancy group).
>
> Jon.
>
>
> _______________________________________________
> rhelv6-list mailing list
> rhelv6-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rhelv6-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20110117/baf2a2e0/attachment.htm>


More information about the rhelv6-list mailing list