+++ This bug was initially created as a clone of Bug #339891 +++
Escalated to Bugzilla from IssueTracker
-- Additional comment from email@example.com on 2007-10-19 11:21 EST --
Customer RHID: 561660
RedHat Bugzilla References: unknown
Description of problem: This customer ran into a problem with their multipath
bindings after a system reboot. They had a working configuration defined in
/var/lib/multipath/bindings, but when the system rebooted, some of the path
names either didn't exist, or were assigned to the wrong paths. This caused
much grief with subsequent filesystem mounts. What we found was that they had
/var as a separate filesytem, and the multipath (and lvm) commands to configure
the paths and devices were being run out of rc.sysinit before /var had been mounted.
How reproducible: Every time the system rebooted.
Steps to Reproduce:
1. Configure your system with /var as a mounted filesystem.
2. Configure multipath bindings that are different from the default bindings/order.
Actual results: The bindings you end up with are the defaults.
Expected results: The bindings you end up with are the ones you specified in the
Additional info: Unless you absolutely forbid mounting /var on a separate file
system, key rc.sysinit startup utilities should *never* use /var for
configuration or locking information. The lvm and multipath tools should keep
their startup critical config files in /etc.
This event sent from IssueTracker by tdunnon [SEG - Feature Request]
Multipath now uses /etc/multipath/bindings
Release note added. If any revisions are required, please set the
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.
The location of the multipath user-friendly-names bindings file has been moved from /var/lib/multipath/bindings to /etc/multipath/bindings. Upgrading from a previous version of device-mapper-multipath will copy your existing bindings file to this location, and turn the old bindings file into a symlink pointing to the new file.
Can we close this now?