Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Because dm_multipath is now loaded from the initrd in RHEL6, internal bootdisks can not be blacklisted with /etc/multipath.conf.
In RHEL5, multipath.conf could be used to blacklist any internal (single pathed) devices on the system.
Version-Release number of selected component (if applicable):
RHEL 6.x
How reproducible:
Have a internal boot disk with a single path.
Additional info:
If we could add a single parameter to the defaults for dm_multipath then when multipath starts in the initrd it would ignore single path devices such as internal boot disks.
Adding this as the defaults would solve this issue.
defaults {
find_multipaths yes
}
Without this, you are forced to rebuild your initrd and replace the /etc/multipath.conf in the initramfs. In a large enterprise envrionment, frankly that is not a solution, we use kickstart and automated deployments and can't be manually running dracut on hundreds and hundreds of systems manually to update their initramfs.
It seems like making this the default used in the initrd environment would help fix this issue, and at the same time let multipath still manage any devices it found multiple paths existing during the init.
I agree that having multipath automatically pick up all the devices in sees in the initramfs is a bad thing, and this is one possible solution, but why is
multipath being added to the initramfs by default in the first place? Also, by default, multipath doesn't install a config file, and blacklists everything, so this seems like it's an Anaconda issue.
I agree. I would definitely question the need for multipath to be in the init and why it can not be started later as it was in RHEL5.
It caused several kickstart bugs that I logged during the RHEL6 beta and had to work around.
The real problem is that because its starting in the init, this has rendered the /etc/multipath.conf file useless and your forcing users to have to modify their initrd image to make changes and really, how many people out there know how to do that outside of us hardcore types?
Anaconda does create /etc/multipath.conf only if any dm-multipath devices are found. That means that in your case, Don, we probably detected a multipath device in your system that is not a multipath and should be blacklisted.
Can I see the logs from the installation and the /etc/multipath.conf we generated? Or even better --- is there a beaker machine where this is reproducible?
Thank you.
(In reply to comment #3)
> I agree. I would definitely question the need for multipath to be in the init
> and why it can not be started later as it was in RHEL5.
>
It is necessary if the root or boot devices are multipathed, but otherwise, you shouldn't need to.
Description of problem: Because dm_multipath is now loaded from the initrd in RHEL6, internal bootdisks can not be blacklisted with /etc/multipath.conf. In RHEL5, multipath.conf could be used to blacklist any internal (single pathed) devices on the system. Version-Release number of selected component (if applicable): RHEL 6.x How reproducible: Have a internal boot disk with a single path. Additional info: If we could add a single parameter to the defaults for dm_multipath then when multipath starts in the initrd it would ignore single path devices such as internal boot disks. Adding this as the defaults would solve this issue. defaults { find_multipaths yes } Without this, you are forced to rebuild your initrd and replace the /etc/multipath.conf in the initramfs. In a large enterprise envrionment, frankly that is not a solution, we use kickstart and automated deployments and can't be manually running dracut on hundreds and hundreds of systems manually to update their initramfs. It seems like making this the default used in the initrd environment would help fix this issue, and at the same time let multipath still manage any devices it found multiple paths existing during the init.