| Summary: | Now that dm_multipath is in initrd for RHEL6, internal boot can not be blacklisted | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Don Hoover <donhoover> |
| Component: | anaconda | Assignee: | Martin Gracik <mgracik> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Release Test Team <release-test-team> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | agk, akozumpl, bmarzins, dmach, dwysocha, heinzm, mbroz, prajnoha, prockai, zkabelac |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-11-22 21:40:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 756082 | ||
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.