Bug 409741 - device-mapper not utilizing friendly names
device-mapper not utilizing friendly names
Status: CLOSED DUPLICATE of bug 357331
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Ben Marzinski
Corey Marthaler
Depends On:
  Show dependency treegraph
Reported: 2007-12-03 23:00 EST by Barrett Wendt
Modified: 2010-01-11 21:39 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-02 13:22:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fstab (1.80 KB, text/plain)
2007-12-31 11:01 EST, Barrett Wendt
no flags Details
multipath (12 bytes, text/plain)
2007-12-31 11:02 EST, Barrett Wendt
no flags Details
multipath.conf (6.79 KB, text/plain)
2007-12-31 11:03 EST, Barrett Wendt
no flags Details
redhat-release (51 bytes, text/plain)
2007-12-31 11:04 EST, Barrett Wendt
no flags Details

  None (edit)
Description Barrett Wendt 2007-12-03 23:00:37 EST
Description of problem: 
Device-mapper is not utilizing friendly names even though 
the "user_friendly_names yes" option is set in multipath.conf

Version-Release number of selected component (if applicable): 
Kernel 2.6.18-53.el5
Device-mapper 0.4.7-12.el5

How reproducible: 
Every reboot of the system

Steps to Reproduce:
1. Reboot the system
2. Issue the command `multipath -ll` to view non-friendly names
3. To correct run `multipath` This rebuilds the devices using friendly names
Actual results:
Example output from `multipath -ll` after a reboot; 
3600507630efe10020000000000000064dm-35 IBM,1750500

Example output after running `multipath`
3600507630efe10020000000000000064: rename 3600507630efe10020000000000000064 to 
mpath34: mpath34 (3600507630efe10020000000000000064)  IBM,1750500

New output from `multipath -ll` 
mpath34 (3600507630efe10020000000000000064) dm-35 IBM,1750500
[size=50G][features=1 queue_if_no_path][hwhandler=0]

Expected results:

Additional info:
Comment 1 Ben Marzinski 2007-12-11 11:25:48 EST
This is most likely an issue with the initrd.  If you multiphath paths are
loaded in the initrd, any changes that were made to the multipath configuration
file will not be reflected in the devices after reboot until the initrd is

To solve this, set up the devices like you would like them, and then remake the
initrd with mkinitrd.
Comment 2 Barrett Wendt 2007-12-12 15:48:20 EST
I tested this and still have the same issue. I also was able to replicate this 
problem on another system running kernel 2.6.18-8.el5


This appears to have started after I upgraded to the 0.4.7-12 multipath tools.
Comment 3 Barrett Wendt 2007-12-12 15:48:55 EST
Do I need to build the initrd without multipath modules maybe?
Comment 4 Ben Marzinski 2007-12-19 17:56:13 EST
I can't reproduce this.  But, this could happen if /etc/ was on a sperate file
system from /, and you started your multipath devices before you mounted /etc/.
Do you have /etc/ on a seperate file system?

Otherwise, can you attach the following files:

/etc/sysconfig/mkinitrd/multipath (if you have it)
Comment 5 Barrett Wendt 2007-12-31 11:01:32 EST
Created attachment 290582 [details]
Comment 6 Barrett Wendt 2007-12-31 11:01:58 EST
Sorry for the slow reply, I was on vacation over Christmas. 

/etc is not a seperate filesystem so this isn't the problem. However during 
boot I do get the following error which may be having some effect.

"Cannot make directory [/var/lib] : Read-only file system

I get this message many times but then the system boots normally. Once 
booted /var/lib is there and permissions are set to root:root 755. The actual 
bindings file is set to 600. This is a new build of RHEL5 and I have always 
seen this message. I have always assumed this was a timing issue at boot and 
up until now have seen no issues caused by this. This may not be causing the 
multipath issue but since the bindings file is located in /var/lib maybe it is.
Comment 7 Barrett Wendt 2007-12-31 11:02:51 EST
Created attachment 290583 [details]
Comment 8 Barrett Wendt 2007-12-31 11:03:22 EST
Created attachment 290584 [details]
Comment 9 Barrett Wendt 2007-12-31 11:04:19 EST
Created attachment 290585 [details]
Comment 10 Ben Marzinski 2008-01-02 13:22:24 EST
I'm pretty sure that I understand what your problem is now.  Looking at your
/etc/sysconfig/mkinitrd/multipath file from comment #7, multipath is probably
not being run by your initrd. However, it is being run before /var is mounted or
root is remounted read/write.  Since multipath cannot read the bindings file or
create one, it simply gives up on the user friendly names.  I've never seen this
exact error before, but I've seen similar problems.  There is already a fix for
this that will be in RHEL 5.2. You will be able to change your bindings file
location in /etc/multipath.conf

In the mean time, there are some workarounds, but none of them are great.
Probably the easiest one is to copy /var/lib/multipath/bindings to a temporary
location, unmount the device that is currently mounted on /var, make a
/var/lib/multipath/bindings file on the root filesystem, and copy you regular
bindings file to that.  That way, before /var is mounted, the machine will still
see the same bindings file.

I don't understand why upgrading the device-mapper-multipath package would have
anything to do with this, or why you didn't see this problem before, if you've
were seeing the same error message before. But regardless, I'm pretty sure from
the message in Comment #6, that this is your problem, and in will be fixed in
RHEL 5.2

*** This bug has been marked as a duplicate of 357331 ***
Comment 11 Blaz Podrzaj 2008-03-04 04:42:55 EST
This happens if you have / and /var on separate partitions. When you boot your
system with no disks over FC/iSCSI attached everything goes fine. When you
attache  those disks and do scsi rescan and after that execute 'multipath -v2'
the /var/lib/multipath/bindings is being created considering you have previously
edited /etc/multipath.conf and added 'user_friendly_names yes' option. After you
reboot multipath routine from rc.sysinit comes after / partition was mounted and
just before any other partition has been mounted. Because there is no /var/lib
(hence no /var/lib/multipath/bindings) at this point, you get multipath devices
being made with their wwid names instead of friendly ones.

There are two more or less solid solutions to this problem. One is to make an
alias in /etc/multipath.conf for every single multipath wwid that you have
attached. And second is to move /var/lib/multipath/bindings to let say
/etc/multipath.bindings (my choice) and make a soft link
/var/lib/multipath/bindings that point to it. You then have to boot into single
user mode executing 'init 1', unmount /var (most probably you will have to
unmount /var/lib/nfs/rpc_pipefs before), go into empty /var, make lib/multipath/
subdirectories and also make there soft link /var/lib/multipath/bindings that
point to /etc/multipath.bindings.

These two solutions are only valid and show results if multipath routine isn't
integrated into your initramfs image. If you don't have / partition on multipath
device, you don't need multipath routine in your initramfs.

Note You need to log in before you can comment on or make changes to this bug.