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.
Bug 630911 - [NetApp 6.1 bug] bindings file issues with RHEL 6.0 root on dm-multipath installation
Summary: [NetApp 6.1 bug] bindings file issues with RHEL 6.0 root on dm-multipath inst...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dracut
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 6.1
Assignee: Harald Hoyer
QA Contact: Martin Banas
URL:
Whiteboard:
Depends On:
Blocks: 580566
TreeView+ depends on / blocked
 
Reported: 2010-09-07 10:44 UTC by Rajashekhar M A
Modified: 2015-09-28 02:06 UTC (History)
23 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When multipath is configured to use user_friendly names, it stores the binding between the wwid and the alias in /etc/multipath/bindings. multipath uses this file in initramfs when creating devices during early boot, and in the root file system during normal operation. These files were not synchronized during initramfs creation, which resulted in naming conflicts that prevented new multipath devices from being created after boot. To work around this, the bindings for the devices in /etc/multipath/bindings must be included in the initramfs. This can be done by running "dracut -f".
Clone Of:
Environment:
Last Closed: 2011-05-19 11:53:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
bindings file, multipath.conf, and multipath –v3 command output (47.24 KB, application/zip)
2010-09-07 10:44 UTC, Rajashekhar M A 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0523 0 normal SHIPPED_LIVE dracut bug fix and enhancement update 2011-05-18 17:44:57 UTC

Description Rajashekhar M A 2010-09-07 10:44:21 UTC 
Created attachment 443480 [details]
bindings file, multipath.conf, and multipath –v3 command output

Description of problem:

When RHEL 6.0 is installed on a dm-multipath device, anaconda does not create the /etc/multipath/bindings file with an entry for the root LUN. 

Also, after installation, when new LUNs are mapped and dm-multipath devices are configured, the /etc/multipath/bindings file gets created by multipath with wrong WWID entries for the dm-multipath device corresponding to the root LUN:

# cat /etc/multipath/bindings
# Multipath bindings, Version : 1.0
# NOTE: this file is automatically maintained by the multipath program.
# You should not need to edit this file in normal circumstances.
#
# Format:
# alias wwid
#
mpatha 360a98000486e2f66426f59514650634f
mpathb 360a98000486e2f65686f59514650586d
#

# multipath -ll mpatha
mpatha (360a98000486e2f66426f5831337a326e) dm-0 NETAPP,LUN
size=15G features='0' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 2:0:0:0  sda  8:0     active ready running
| |- 2:0:2:0  sdfi 130:64  active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
  |- 2:0:1:0  sdap 66:144  active ready running
  |- 2:0:3:0  sdgx 132:208 active ready running

In the bindings file, the alias corresponding to mpatha has a different UUID entry. As a result, creation of the dm-multipath device with the WWID 360a98000486e2f66426f59514650634f, fails.


Version-Release number of selected component (if applicable):

anaconda version 13.21.81
device-mapper-multipath-0.4.9-28.el6.x86_64


How reproducible:

Always


Steps to Reproduce:

1. Install RHEL 6.0 on a remote LUN.
2. After installation completes and the system reboots, check /etc/multipath/bindings file.

Actual results:

The file /etc/multipath/bindings does not exist. Now, map new LUNs on the controllers and run multipath –v3. Creation of dm-multipath devices for all the LUNs fails.


Expected results:

/etc/multipath/bindings file should have been created by anaconda and multipath should add proper entries into the bindings file corresponding to the root LUN.


Additional info:

Attached is a zip file having the bindings file, multipath.conf, and multipath –v3 command output.
Comment 2 Ben Marzinski 2010-09-07 15:29:57 UTC 
This is either an anaconda bug or a dracut bug.  When the initramfs is made, it must make sure to keep the /etc/multipath/bindings file in the initramfs in sync with the one in the regular filesystem. This is true during install as well.  If the initramfs has a bindings file entry that conflicts with one in the regular filesystem, this will cause multipath problems.
Comment 3 Harald Hoyer 2010-09-07 16:33:44 UTC 
patch might be:

diff -up dracut-004/modules.d/90multipath/install.mp dracut-004/modules.d/90multipath/install
--- dracut-004/modules.d/90multipath/install.mp	2010-09-07 18:32:57.000000000 +0200
+++ dracut-004/modules.d/90multipath/install	2010-09-07 18:33:09.000000000 +0200
@@ -16,7 +16,7 @@ for f in  \
     /sbin/xdrgetprio \
     /etc/xdrdevices.conf \
     /etc/multipath.conf \
-    /etc/multipath/wwids \
+    /etc/multipath/* \
     $(ls $LIBDIR/libmultipath* $LIBDIR/multipath/* 2>/dev/null) \
     	;do
     [ -e "$f" ] && inst "$f"
Comment 7 RHEL Program Management 2010-09-07 18:57:55 UTC 
Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.

If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.
Comment 8 Andrius Benokraitis 2010-09-07 19:04:40 UTC 
(In reply to comment #7)
> Thank you for your bug report. This issue was evaluated for inclusion
> in the current release of Red Hat Enterprise Linux. Unfortunately, we
> are unable to address this request in the current release. Because we
> are in the final stage of Red Hat Enterprise Linux 6 development, only
> significant, release-blocking issues involving serious regressions and
> data corruption can be considered.
> 
> If you believe this issue meets the release blocking criteria as
> defined and communicated to you by your Red Hat Support representative,
> please ask your representative to file this issue as a blocker for the
> current release. Otherwise, ask that it be evaluated for inclusion in
> the next minor release of Red Hat Enterprise Linux.

Ignore this for now.
Comment 9 David Cantrell 2010-09-07 19:13:44 UTC 
Does this problem prevent the system from booting up correctly after installation?
Comment 10 Ben Marzinski 2010-09-07 20:31:11 UTC 
It shouldn't, as long as booting up doesn't require both mounting a multipath device that is created in the initramfs, and mounting another one that is created after the root fs has been mounted. Even in this case, it might still work, since those devices hopefully got setup together during install, so they won't have conflicting user-friendly-names.

The problem will happen with any new multipath devices that are created after bootup.  The solution is to manually enter the bindings for the root devices into /etc/multipath/bindings. This will cause the new devices to pick non-conflicting user-friendly-names.

Can someone verify that this fixes the problem?
Comment 11 Rajashekhar M A 2010-09-08 12:00:31 UTC 
Yes, if we manually edit the bindings file with the wwid for root device, multipath is able to configure the rest of the devices as expected.
Comment 12 Denise Dumas 2010-09-08 15:49:08 UTC 
So given where we are with RHEL6 and since we have a workaround here, I'm going to move this to 6.1 and ask Ben to add a RHEL6 release note.
Comment 13 Ben Marzinski 2010-09-08 20:20:44 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When multipath is configured to use user_friendly_names, it stores the binding between the wwid and the alias in /etc/multipath/bindings.  When multipath creates devices in early bootup, (for example when the root filesystem is on a multipath device) it looks at /etc/multipath/bindings in the initramfs. When it creates devices during normal operation, it looks at /etc/multipath/bindings in the root filesystem. Currently, these two files aren't synced during initramfs creation.  Because of this, there may be naming conflicts which keep new multipath devices from being created after bootup.  To work around this, the bindings for the devices created by the initramfs must be copied into /etc/multipath/bindings after installation. The format of the bindings is:

<alias><space><wwid>

for example:

mpatha 3600d0230000000000e13955cc3757801
Comment 15 Ryan Lerch 2010-09-29 00:37:42 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1,6 @@
-When multipath is configured to use user_friendly_names, it stores the binding between the wwid and the alias in /etc/multipath/bindings.  When multipath creates devices in early bootup, (for example when the root filesystem is on a multipath device) it looks at /etc/multipath/bindings in the initramfs. When it creates devices during normal operation, it looks at /etc/multipath/bindings in the root filesystem. Currently, these two files aren't synced during initramfs creation.  Because of this, there may be naming conflicts which keep new multipath devices from being created after bootup.  To work around this, the bindings for the devices created by the initramfs must be copied into /etc/multipath/bindings after installation. The format of the bindings is:
+When multipath is configured to use user_friendly_names, it stores the binding between the wwid and the alias in /etc/multipath/bindings. When multipath creates devices in early bootup, (for example when the root filesystem is on a multipath device) it looks at /etc/multipath/bindings in the initramfs. When it creates devices during normal operation, it looks at /etc/multipath/bindings in the root filesystem. Currently, these two files aren't synced during initramfs creation. Because of this, there may be naming conflicts which keep new multipath devices from being created after bootup. To work around this, the bindings for the devices created by the initramfs must be copied into /etc/multipath/bindings after installation. The format of the bindings is:
 
 <alias><space><wwid>
-
 for example:
 
 mpatha 3600d0230000000000e13955cc3757801
Comment 16 Harald Hoyer 2010-09-29 16:02:13 UTC 
two other workarounds would be:

1. create every initramfs with:

# dracut --include  /etc/multipath/bindings

or

2. create a second initramfs image

# mkdir -p /var/lib/dracut/overlay/etc/multipath
# cp /etc/multipath/bindings /var/lib/dracut/overlay/etc/multipath
# cd /var/lib/dracut/overlay/
# find . |cpio --quiet -H newc -o | gzip -9 > /boot/initramfs-mp-bind.img

and add the initramfs to /etc/grub.conf

title Red Hat Enterprise Linux
        root (hd0,0)
        kernel /vmlinuz-xxx.x86_64 ro....
        initrd /initramfs-xxx.x86_64.img
        initrd /initramfs-mp-bind.img
Comment 17 Phil Knirsch 2010-11-18 14:06:16 UTC 
*** Bug 636668 has been marked as a duplicate of this bug. ***
Comment 22 Harald Hoyer 2011-02-16 10:53:44 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,6 +1,2 @@
-When multipath is configured to use user_friendly_names, it stores the binding between the wwid and the alias in /etc/multipath/bindings. When multipath creates devices in early bootup, (for example when the root filesystem is on a multipath device) it looks at /etc/multipath/bindings in the initramfs. When it creates devices during normal operation, it looks at /etc/multipath/bindings in the root filesystem. Currently, these two files aren't synced during initramfs creation. Because of this, there may be naming conflicts which keep new multipath devices from being created after bootup. To work around this, the bindings for the devices created by the initramfs must be copied into /etc/multipath/bindings after installation. The format of the bindings is:
+When multipath is configured to use user_friendly_names, it stores the binding between the wwid and the alias in /etc/multipath/bindings. When multipath creates devices in early bootup, (for example when the root filesystem is on a multipath device) it looks at /etc/multipath/bindings in the initramfs. When it creates devices during normal operation, it looks at /etc/multipath/bindings in the root filesystem. Currently, these two files aren't synced during initramfs creation. Because of this, there may be naming conflicts which keep new multipath devices from being created after bootup. To work around this, the bindings for the devices /etc/multipath/bindings has to be included in the initramfs. This can be done by running:
-
+# dracut -f-<alias><space><wwid>
-for example:
-
-mpatha 3600d0230000000000e13955cc3757801
Comment 24 Chris Ward 2011-04-06 11:06:15 UTC 
~~ Partners and Customers ~~

This bug was included in RHEL 6.1 Beta. Please confirm the status of this request as soon as possible.

If you're having problems accessing 6.1 bits, are delayed in your test execution or find in testing that the request was not addressed adequately, please let us know.

Thanks!
Comment 25 Rajashekhar M A 2011-04-12 12:29:44 UTC 
Checked with RHEL6.1 snap2. This issue seems to have got resolved.

Versions:
dracut-004-46.el6.noarch
dracut-kernel-004-46.el6.noarch

Thank you.
Comment 27 Laura Bailey 2011-05-05 06:26:02 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,2 +1 @@
-When multipath is configured to use user_friendly_names, it stores the binding between the wwid and the alias in /etc/multipath/bindings. When multipath creates devices in early bootup, (for example when the root filesystem is on a multipath device) it looks at /etc/multipath/bindings in the initramfs. When it creates devices during normal operation, it looks at /etc/multipath/bindings in the root filesystem. Currently, these two files aren't synced during initramfs creation. Because of this, there may be naming conflicts which keep new multipath devices from being created after bootup. To work around this, the bindings for the devices /etc/multipath/bindings has to be included in the initramfs. This can be done by running:
+When multipath is configured to use user_friendly names, it stores the binding between the wwid and the alias in /etc/multipath/bindings. multipath uses this file in initramfs when creating devices during early boot, and in the root file system during normal operation. These files were not synchronized during initramfs creation, which resulted in naming conflicts that prevented new multipath devices from being created after boot. To work around this, the bindings for the devices in /etc/multipath/bindings must be included in the initramfs. This can be done by running "dracut -f".-# dracut -f
Comment 28 errata-xmlrpc 2011-05-19 11:53:46 UTC 
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-2011-0523.html
Note You need to log in before you can comment on or make changes to this bug.