Sigh, after working through a very very long support ticket on this issue I received a semi complete response. I have not had a chance yet to test the proposed configuration nor have I received an answer to whether or not this would be supported when upgrading from RHEL3 to RHEL4 (either manually or via a satellite upgrade). I am not really happy with the complexity involved in their "supported solution".
RedHat Support said:
"Very well. I have discussed the multipath/mdadm options with our escalation team and they have recommended the following as a practical workaround to your request. Allow me to address your RHEL 3 to RHEL4 upgrade and Satellite concerns on a separate communication:
You can install a system that will have *all* devices multipathed through one of the following methods. Keep in mind that the install will be performed through one path only, since there is no need to have both paths active during the installation. The paths will become active after the first boot:
1) Kickstart install:
a) In the main section of the kickstart configuration file, define the
partitions/filesystems as usual ( /, /boot, swap, etc).
b) In the %post section, include the necessary commands to do the
following:
- Unmount all the filesystems
- Resize the filesystems to be 64k smaller so the md devices can be
created on these. You can use the "resize2fs" command to accomplish this (man resize2fs).
- Create the multipath devices following the instructions specified in:
http://kbase.redhat.com/faq/FAQ_80_3187.shtm
- Create/run a script to change the boot loader configuration file (lilo or grub) to specify the md device for root instead of using the label. For example, if the root device is /dev/md0, instead of reading:
kernel /vmlinuz-2.4.21-20.ELsmp ro root=LABEL=/
it should read:
kernel /vmlinuz-2.4.21-20.ELsmp ro root=/dev/md0
You should be able to use this kickstart configuration file through your Satellite Provisioning.
2) Manual install:
a) Proceed with the manual installation and define the partitions/filesystems as usual ( /, /boot, swap, etc).
b) After the installation is completed, boot the system into rescue mode
keeping all the filesystems *unmounted*:
- Resize the filesystems to be 64k smaller so the md devices can be
created on these.
- Create the multipath devices following the instructions specified in:
http://kbase.redhat.com/faq/FAQ_80_3187.shtml
- Manually change the boot loader configuration file (lilo or grub) as
suggested in the kickstart install method.
After using either of these methods, the system should boot and see the multipath devices without a problem."
On Thu, 17 Feb 2005, D Canfield wrote:
It's great that the qla2300 module is in the mainline kernel tree, but what about the qla2300_conf module that is required to configure this card for any kind of enterprise/production setting (e.g failover/multipathing particularly on /boot)? Should the RHEL3 bug be re-opened, or should this be a whole new bugzilla entry?
I know, I know, the preferred method is the md driver, and I'm all for doing it that way once that way works. But every time a Red Hatter comes out and declares that md is the One True Way, they always crawl back into the woodwork when we ask how to do multipath /boot using md, especially from anaconda (all of which works via the qla2300 method). Have I overlooked something about the md method having been made complete when I wasn't looking (and I apologize if I have)? If not, can we please have the qla2300_conf module back, so that RHEL4 is feature complete compared to RHEL3, especially since there has been no formal notification that the qla2300_conf module was deprecated in EL3?
Thanks
DC
-- nahant-list mailing list nahant-list redhat com http://www.redhat.com/mailman/listinfo/nahant-list
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature