neo3 matrix | 11 Jan 11:34 2011
Picon

module load order changed in initramfs

I have recently installed RHEL 6.0 GA.
I want to find out what are the modules get loaded  from initramfs image in RHEL 6.

Upto RHEL 5, we can directly see "insmod" and "modprobe" calls and their sequences in "init" file from initrd.img.

But now, in RHEL 6, initramfs  doesn't have direct calls to "insmod" or "modprobe" inside init file. I walked through init script and also "grep"ed  complete initramfs for insmod/modprobe, got very few of the module names then actual loaded modules.

I even tried searching in /etc/rcX....., /etc/modprobe.d, etc.etc.

Can anybody tell me what is the driver load order in RHEL 6 and how can I find it out?

_______________________________________________
rhelv6-list mailing list
rhelv6-list@...
https://www.redhat.com/mailman/listinfo/rhelv6-list
Jon Masters | 11 Jan 12:05 2011
Picon

Re: module load order changed in initramfs

On Tue, 2011-01-11 at 16:04 +0530, neo3 matrix wrote:

> Can anybody tell me what is the driver load order in RHEL 6 and how
> can I find it out?

Hello,

Module loading for hardware devices in RHEL6 initramfs is determined by
calls udev makes to modprobe, so in theory you will see very few as it's
a standard script. The order of loading may change from RHEL5, but
broadly follows the order in which the kernel enumerates devices.

I specifically changed module load ordering in RHEL6 to remove the
"parallel" loading approach taken in Fedora. That was cute for slight
improvement in boot speed, but it undermined predictability. Therefore,
the version of udev in RHEL6 will make *one call at a time*, and you
should always see the same ordering on each boot.

Can you let us know specifically what problem you are having? Possibly
by filing a support case or opening a Bugzilla?

Jon.
Farkas Levente | 11 Jan 12:21 2011

Re: module load order changed in initramfs

On Tue, Jan 11, 2011 at 12:05, Jon Masters <jcm@...> wrote:
> On Tue, 2011-01-11 at 16:04 +0530, neo3 matrix wrote:
>
>> Can anybody tell me what is the driver load order in RHEL 6 and how
>> can I find it out?
>
> Hello,
>
> Module loading for hardware devices in RHEL6 initramfs is determined by
> calls udev makes to modprobe, so in theory you will see very few as it's
> a standard script. The order of loading may change from RHEL5, but
> broadly follows the order in which the kernel enumerates devices.
>
> I specifically changed module load ordering in RHEL6 to remove the
> "parallel" loading approach taken in Fedora. That was cute for slight
> improvement in boot speed, but it undermined predictability. Therefore,
> the version of udev in RHEL6 will make *one call at a time*, and you
> should always see the same ordering on each boot.
>
> Can you let us know specifically what problem you are having? Possibly
> by filing a support case or opening a Bugzilla?

what's the current preferred mode to change the order?
eg. for us sata_promise load before ahci which cause the on
motherboard sata contorller's disk is loaded after the additional sata
pci card's disk so sda become sde in some case. so we modify grub
driverload=ata_piix driverload=ahci
and run this on all machine
-------------------------------------------
echo "PREMODS='$PREMODS ata_piix ahci'" > /etc/sysconfig/mkinitrd/sata_disk
chmod +x /etc/sysconfig/mkinitrd/sata_disk
/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install
`rpm -q --qf "%{version}-%{release}" kernel`
-------------------------------------------
anyway none of the above documented by rh (at least we can't find it).
regards.

--

-- 
  Levente                               "Si vis pacem para bellum!"
John Haxby | 11 Jan 16:06 2011
Picon

Re: module load order changed in initramfs



On 11 January 2011 11:21, Farkas Levente <lfarkas <at> lfarkas.org> wrote:

what's the current preferred mode to change the order?
eg. for us sata_promise load before ahci which cause the on
motherboard sata contorller's disk is loaded after the additional sata
pci card's disk so sda become sde in some case. so we modify grub
driverload=ata_piix driverload=ahci
and run this on all machine


Probably the right thing to do is to stop depending on the device name and pick something that doesn't change, eg the file system uuid.

--
Phear the Penguin
_______________________________________________
rhelv6-list mailing list
rhelv6-list@...
https://www.redhat.com/mailman/listinfo/rhelv6-list
Farkas Levente | 11 Jan 16:22 2011

Re: module load order changed in initramfs

On 01/11/2011 04:06 PM, John Haxby wrote:
> 
> 
> On 11 January 2011 11:21, Farkas Levente <lfarkas@...
> <mailto:lfarkas@...>> wrote:
> 
> 
>     what's the current preferred mode to change the order?
>     eg. for us sata_promise load before ahci which cause the on
>     motherboard sata contorller's disk is loaded after the additional sata
>     pci card's disk so sda become sde in some case. so we modify grub
>     driverload=ata_piix driverload=ahci
>     and run this on all machine
> 
> 
> 
> Probably the right thing to do is to stop depending on the device name
> and pick something that doesn't change, eg the file system uuid.

which you're not able to do during kickstart install since the
filesystem not exist before the install, but still would like to use a
"small" system disk and many bigger data disks...

--

-- 
  Levente                               "Si vis pacem para bellum!"
Alois Treindl | 11 Jan 15:04 2011
Picon

mingrate sendmail to postfix

My new RHEL 6 installation does not contain sendmail as a service, only 
postfix.

Are there any instructions how to migrate a sendmail mail server 
installation to postfix?

In my case, this includes in /etc/mail these configuration files
sendmail.mc
   with settings for procmail, for rbl-plus.mail-abuse.org, for 
sbl.spamhaus.org, for avmilter etc

Or can I continue to use sendmail as MTA on RHEL6. If yes, how to 
configure at kickstart install?
Greg_Swift | 11 Jan 15:25 2011

Re: mingrate sendmail to postfix


rhelv6-list-bounces@... wrote on 01/11/2011 08:04:32 AM:

> Or can I continue to use sendmail as MTA on RHEL6. If yes, how to
> configure at kickstart install?

don't have a fix for how to configure postfix over sendmail other than
research it.

however if you want to use sendmail, sendmail and sendmail-cf are both in
RHEL6, install them.  What I'm not seeing, however is the old
system-switch-mail that will do all the alternatives adjustments for you.
It looks like its been deprecated in favor of direct use of the
'alternatives' application.

http://linuxhelp.blogspot.com/2005/06/change-your-mail-transport-agent-mta.html

or more directly:

alternatives --config mta

-greg
Alois Treindl | 12 Jan 22:34 2011
Picon

Re: mingrate sendmail to postfix

Thanks, I also have found out shortly after asking my question that
yum install sendmail
does the job.

On 11.01.11 15:25, Greg_Swift@... wrote:
>
>
> rhelv6-list-bounces@... wrote on 01/11/2011 08:04:32 AM:
>
>> Or can I continue to use sendmail as MTA on RHEL6. If yes, how to
>> configure at kickstart install?
>
> don't have a fix for how to configure postfix over sendmail other than
> research it.
>
> however if you want to use sendmail, sendmail and sendmail-cf are both in
> RHEL6, install them.  What I'm not seeing, however is the old
> system-switch-mail that will do all the alternatives adjustments for you.
> It looks like its been deprecated in favor of direct use of the
> 'alternatives' application.
>
> http://linuxhelp.blogspot.com/2005/06/change-your-mail-transport-agent-mta.html
>
> or more directly:
>
> alternatives --config mta
>
>
> -greg
>
> _______________________________________________
> rhelv6-list mailing list
> rhelv6-list@...
> https://www.redhat.com/mailman/listinfo/rhelv6-list
neo3 matrix | 11 Jan 15:30 2011
Picon

Re: module load order changed in initramfs

Hi Jon,

Thank you very much for replying.

The specific problem which I am facing is:-
I am working on a Linux disaster recovery product where we used to restore the client to its original state after once we have a full backup of client.
While restoring the client, we boot the client with minimum os image (actually with initramfs) .

Now, to properly boot the client using initramfs, we need to provide proper driver load order/sequence to detect disks and other hardware, especially for SCSI devices. Upto RHEL5, we can easily get the drivers and their respective load order/sequence by just "grep"ing insmod or modprobe on the "init" script.

In RHEL6, as per your comments, calls to modprobe made by udev decides driver loading order and we can see very few module names in standard script.

So, my question is how can I get the modules list and their load order from initramfs?
If not from initramfs,  is there any other way to get it from a normal running system?
This information is critical for me to provide proper drivers and their load order during restoration.

Can you please give me some guidelines on this front?

--
Neo












On Tue, Jan 11, 2011 at 4:35 PM, Jon Masters <jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
On Tue, 2011-01-11 at 16:04 +0530, neo3 matrix wrote:

> Can anybody tell me what is the driver load order in RHEL 6 and how
> can I find it out?

Hello,

Module loading for hardware devices in RHEL6 initramfs is determined by
calls udev makes to modprobe, so in theory you will see very few as it's
a standard script. The order of loading may change from RHEL5, but
broadly follows the order in which the kernel enumerates devices.

I specifically changed module load ordering in RHEL6 to remove the
"parallel" loading approach taken in Fedora. That was cute for slight
improvement in boot speed, but it undermined predictability. Therefore,
the version of udev in RHEL6 will make *one call at a time*, and you
should always see the same ordering on each boot.

Can you let us know specifically what problem you are having? Possibly
by filing a support case or opening a Bugzilla?

Jon.


_______________________________________________
rhelv6-list mailing list
rhelv6-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
https://www.redhat.com/mailman/listinfo/rhelv6-list

_______________________________________________
rhelv6-list mailing list
rhelv6-list@...
https://www.redhat.com/mailman/listinfo/rhelv6-list
John Haxby | 11 Jan 16:04 2011
Picon

Re: module load order changed in initramfs



On 11 January 2011 14:30, neo3 matrix <neo3matrix <at> gmail.com> wrote:

So, my question is how can I get the modules list and their load order from initramfs?
If not from initramfs,  is there any other way to get it from a normal running system?
This information is critical for me to provide proper drivers and their load order during restoration.


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, or if it is the same, that it will be consistent across different machines (even identically configured different machines).

 
Can you please give me some guidelines on this front?

I think you need a different approach.  If you look at /etc/fstab on an RHEL6 system you'll see that file systems are either identified by a logical volume name or by a UID  -- this is to get away from needing to know what file system is associated with which device (eg /dev/sda, /dev/sde, etc).  Nothing in the boot sequence cares what the underlying device is called -- you can find out, after booting, that (say) UUID=42005eb1-fc91-4ee4-97f5-b453d3896ff0 is actually /dev/sda1.

You might find the various /dev/disk/* directories useful for identifying disks by something less ephemeral than a device name -- /dev/disk/by-uuid is probably the best one.

jch
_______________________________________________
rhelv6-list mailing list
rhelv6-list@...
https://www.redhat.com/mailman/listinfo/rhelv6-list
Jon Masters | 11 Jan 17:04 2011
Picon

Re: module load order changed in initramfs

On Tue, 2011-01-11 at 15:04 +0000, John Haxby wrote:
> On 11 January 2011 14:30, neo3 matrix <neo3matrix@...> wrote:

> > So, my question is how can I get the modules list and their load
> > order from initramfs?

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.

> > If not from initramfs,  is there any other way to get it from a
> > normal running system?

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. Is it that you're emulating the running
system, or driving a system image under a virtual machine, and don't
want to actually run any of the bits that came with it? (perhaps for
some kind of forensics purpose in addition to disaster recovery?).

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

> or if it is the same, that it will be consistent across different
> machines (even identically configured different machines).

This is true. Even similar model numbers could have different hardware
bus structures, and different detection ordering therefore.

Jon.
John Haxby | 11 Jan 20:39 2011
Picon

Re: module load order changed in initramfs



On 11 January 2011 16:04, Jon Masters <jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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@...
https://www.redhat.com/mailman/listinfo/rhelv6-list
neo3 matrix | 12 Jan 07:58 2011
Picon

Re: module load order changed in initramfs

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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
https://www.redhat.com/mailman/listinfo/rhelv6-list


_______________________________________________
rhelv6-list mailing list
rhelv6-list@...
https://www.redhat.com/mailman/listinfo/rhelv6-list
Jon Masters | 12 Jan 13:21 2011
Picon

Re: module load order changed in initramfs

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.
neo3 matrix | 17 Jan 07:31 2011
Picon

Re: module load order changed in initramfs

Hi,
sorry for late reply.

Thank you Jon and everybody for valuable advice.
<at> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
https://www.redhat.com/mailman/listinfo/rhelv6-list

_______________________________________________
rhelv6-list mailing list
rhelv6-list@...
https://www.redhat.com/mailman/listinfo/rhelv6-list

Gmane