Hi, <br>Thanks for reply.<br><br><div style="margin-left: 40px;"><span style="color: rgb(153, 51, 0);">You don't :) Not directly. It requires the initramfs to actually be run</span><br style="color: rgb(153, 51, 0);">
<span style="color: rgb(153, 51, 0);">and for the module loading to take place in reaction to the kernel</span><br style="color: rgb(153, 51, 0);"><span style="color: rgb(153, 51, 0);">detecting various devices.</span><br>
</div><br>Ok... So I understood that unlike RHEL5, I cannot get drivers and their load order just by digging initramfs without actually running it.<br><br><br><div style="margin-left: 40px; color: rgb(153, 51, 0);">Yea, there is a reasonable expectation that it will be identical across<br>
same boots of the same system, running the same kernel build.<br></div><br>Yes, I am restoring the client image on same system, same hardware and using same kernel build.<br><br><div style="margin-left: 40px; color: rgb(153, 51, 0);">
I'm not sure whether you actually need to duplicate the ordering, or<br>simply the list of modules that were loaded, and I'm still not really<br>sure what you're trying to do.<br></div><br><br>I explain my problem in detail:-<br>
For an RHEL client, if the client gets crashed, then on the same system, same hardware and using same kernel build, we just restore the client<br>to its original state with same OS level, with same initramfs.<br><br>The driver load order I was talking about is, in case of RHEL5, <br>
I fire a command on initrd to get drivers and their load order as follows:-<br><br>Command:if [ -e /etc/redhat-release ] ; then ext=".img" ; else ext="" ; fi ; kernel=`/bin/uname -r`; gunzip -c /boot/initrd-$kernel$ext 2>/dev/null | strings 2>/dev/null | grep -E "insmod /lib|^modprobe " 2>/dev/null | /usr/bin/awk '{ print $2 }' | /usr/bin/awk -F '/' '{ print $NF }' | /usr/bin/awk -F '.' '{ print $1 }'<br>
<br>Output:-<br>ehci-hcd<br>ohci-hcd<br>uhci-hcd<br>jbd<br>ext3<br>scsi_mod<br>sd_mod<br>scsi_transport_sas<br>mptbase<br>mptscsih<br>mptsas<br>shpchp<br>libata<br>ata_piix<br>usb-storage<br>dm-mem-cache<br>dm-mod<br>dm-log<br>
dm-region_hash<br>dm-message<br>dm-raid45<br><br>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.<br>This I cannot do with RHEL6 initramfs as their is no provision of getting drivers and their load order from initramfs on RHEl6.<br>
<br>So, how can I get such type of drivers and their sequence specific to RHEL6?<br><br><b>Eventually, I just need to save the drivers and their load sequence from client while it was running fine, which I want to use during restoration time.</b><br>
<br>One more question:-<br>Can I trust the list shown in "/proc/modules" file on the same client while it was working before crash?<br>Should I follow top-to-bottom sequence showed in the /proc/modules file for the required sequence I am looking for?<br>
<br><br>Thanks,<br>Neo <br><br><div class="gmail_quote">On Wed, Jan 12, 2011 at 1:09 AM, John Haxby <span dir="ltr"><<a href="mailto:john.haxby@gmail.com">john.haxby@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><div class="gmail_quote">On 11 January 2011 16:04, Jon Masters <span dir="ltr"><<a href="mailto:jcm@redhat.com" target="_blank">jcm@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Tue, 2011-01-11 at 15:04 +0000, John Haxby wrote:> I don't think that there is a specific load order: even if you could</div><div class="im"><div>
> detect the order in which devices are discovered (and thereby the<br>
> modules are loaded) there is no guarantee that it will be the same<br>
> next time it is booted<br>
<br>
</div>Yea, there is a reasonable expectation that it will be identical across<br>
same boots of the same system, running the same kernel build. We<br>
intentionally engineered that the system behave this way, in contrast to<br>
the way that Fedora will load many modules at the same time, racing.<br>
<div><br></div></div></blockquote><div><br></div><div>I wonder if this is where I got the idea that some machines don't have a predictable hardware discovery sequence? Or is there some hardware that doesn't have a predictable sequence? I know that adding and removing hardware can upset things royally and that hardware that suddenly springs to life while the system is running is also "interesting" but is there anything that really does vary from boot to boot?</div>
<div><br></div><div>jch </div></div>
<br>_______________________________________________<br>
rhelv6-list mailing list<br>
<a href="mailto:rhelv6-list@redhat.com">rhelv6-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/rhelv6-list" target="_blank">https://www.redhat.com/mailman/listinfo/rhelv6-list</a><br>
<br></blockquote></div><br>