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 <[email protected]> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv6-list >
_______________________________________________ rhelv6-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv6-list
