[rhelv6-list] module load order changed in initramfs

[neo3 matrix]

Hi,
Thanks for  reply.

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 without actually running it.


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.

I'm not sure whether you actually need to duplicate the ordering, or
simply the list of modules that were loaded, and I'm still not really
sure what you're trying to do.


I explain my problem in detail:-
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
to its original state with same OS level, with same initramfs.

The driver load order I was talking about is, in case of RHEL5,
I fire a command on initrd to get drivers and their load order as follows:-

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 }'

Output:-
ehci-hcd
ohci-hcd
uhci-hcd
jbd
ext3
scsi_mod
sd_mod
scsi_transport_sas
mptbase
mptscsih
mptsas
shpchp
libata
ata_piix
usb-storage
dm-mem-cache
dm-mod
dm-log
dm-region_hash
dm-message
dm-raid45

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

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

One more question:-
Can I trust the list shown in "/proc/modules" file on the same client while
it was working before crash?
Should I follow top-to-bottom sequence showed in the /proc/modules file for
the required sequence I am looking for?


Thanks,
Neo

On Wed, Jan 12, 2011 at 1:09 AM, John Haxby <john.haxby at gmail.com> wrote:

>
>
> On 11 January 2011 16:04, Jon Masters <jcm at redhat.com> wrote:
>
>> 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
>> > detect the order in which devices are discovered (and thereby the
>> > modules are loaded) there is no guarantee that it will be the same
>> > next time it is booted
>>
>> Yea, there is a reasonable expectation that it will be identical across
>> same boots of the same system, running the same kernel build. We
>> intentionally engineered that the system behave this way, in contrast to
>> the way that Fedora will load many modules at the same time, racing.
>>
>>
> 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?
>
> jch
>
> _______________________________________________
> 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/20110112/5b946d57/attachment.htm>