Description of problem: mpath boot parameter is not included per default in generic.prm and the installer does not sense/allow when a SCSI device has more than one path. Under z/VM the user can easily modify the generic.prm, but under LPAR, when installed from a mounted DVD image or direct from a DVD drive attached, it is not so easy to change the default generic.prm. That is why it would help adding mpath boot parameter to the default generic.prm. From my experiences with the mpath boot parameter it has no cons and it has a major pro for customer requiring new SCSI multipath installation on the rootfs. How reproducible: Install without "mpath" boot parameter in generic.prm and if you add to SCSI devices which are really two paths to the same physical device, the installer will show them as two differen scsi devices, because the multipath sensing is not active. Actual results: With default generic.prm SCSI multipath installation on rootfs is not possible. User has to manually change the generic.prm adding "mpath" Expected results: Adding the "mpath" will sense with scsi_id if two devices are different paths to the same physical device and they will automatically get grouped with device mapper. Additional info: The disk where /boot is mounted should never be multipathed, since at this point on time the boot loader installed in the disk holding the /boot dir does not support multipath. This should be just documented in the installation guide under partition layout chapter (it used to be documented but got removed when changing some swap recomendations which was independent on the /boot restriction). [Optional] If there is an easy/"low effort" way to check and make sure that the user did not try to define more than one path for the /boot disk, it would be nice to have this semantic in the installer dialog. Otherwise, documentation is fine.
Is 'mpath' a safe no-op on systems that are DASD-only? That is, if you don't need the parameter, does it hurt to include it?
From what I have tested with DASD only systems where I include the "mpath" modifiying generic.prm manually, it is safe and it does not hurt to include it.
Patch to address this issue: diff --git a/bootdisk/s390/generic.prm b/bootdisk/s390/generic.prm index e468761..afecff0 100644 --- a/bootdisk/s390/generic.prm +++ b/bootdisk/s390/generic.prm @@ -1 +1 @@ -root=/dev/ram0 ro ip=off ramdisk_size=40000 +root=/dev/ram0 ro ip=off ramdisk_size=40000 mpath diff --git a/bootdisk/s390x/generic.prm b/bootdisk/s390x/generic.prm index e468761..afecff0 100644 --- a/bootdisk/s390x/generic.prm +++ b/bootdisk/s390x/generic.prm @@ -1 +1 @@ -root=/dev/ram0 ro ip=off ramdisk_size=40000 +root=/dev/ram0 ro ip=off ramdisk_size=40000 mpath Would like to include this in RHEL 5.5 if possible because it's simple.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This enhancement request was evaluated by the full Red Hat Enterprise Linux team for inclusion in a Red Hat Enterprise Linux minor release. As a result of this evaluation, Red Hat has tentatively approved inclusion of this feature in the next Red Hat Enterprise Linux Update minor release. While it is a goal to include this enhancement in the next minor release of Red Hat Enterprise Linux, the enhancement is not yet committed for inclusion in the next minor release pending the next phase of actual code integration and successful Red Hat and partner testing.
generic.prm from RHEL5.5-Server-20100129.nightly (with anaconda-11.1.2.202-2) contains: root=/dev/ram0 ro ip=off ramdisk_size=40000 mpath Moving to VERIFIED.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0194.html