Red Hat Bugzilla – Bug 630911
[NetApp 6.1 bug] bindings file issues with RHEL 6.0 root on dm-multipath installation
Last modified: 2015-09-27 22:06:00 EDT
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.
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.
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"
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.
(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.
Does this problem prevent the system from booting up correctly after installation?
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?
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.
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.
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
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
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
*** Bug 636668 has been marked as a duplicate of this bug. ***
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
~~ 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!
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.
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
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