Bug 409741 - device-mapper not utilizing friendly names
Summary: device-mapper not utilizing friendly names
Keywords:
Status: CLOSED DUPLICATE of bug 357331
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper-multipath
Version: 5.1
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: Ben Marzinski
QA Contact: Corey Marthaler
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-04 04:00 UTC by Barrett Wendt
Modified: 2010-01-12 02:39 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-02 18:22:24 UTC


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

Description Barrett Wendt 2007-12-04 04:00:37 UTC
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 16:25:48 UTC
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
refreshed.

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 20:48:20 UTC
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

device-mapper-1.02.20-1.el5
device-mapper-multipath-0.4.7-12.el5
device-mapper-1.02.20-1.el5

This appears to have started after I upgraded to the 0.4.7-12 multipath tools.


Comment 3 Barrett Wendt 2007-12-12 20:48:55 UTC
Do I need to build the initrd without multipath modules maybe?

Comment 4 Ben Marzinski 2007-12-19 22:56:13 UTC
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/multipath.conf
/etc/sysconfig/mkinitrd/multipath (if you have it)
/etc/redhat-release
/etc/fstab


Comment 5 Barrett Wendt 2007-12-31 16:01:32 UTC
Created attachment 290582 [details]
fstab

Comment 6 Barrett Wendt 2007-12-31 16:01:58 UTC
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 16:02:51 UTC
Created attachment 290583 [details]
multipath

Comment 8 Barrett Wendt 2007-12-31 16:03:22 UTC
Created attachment 290584 [details]
multipath.conf

Comment 9 Barrett Wendt 2007-12-31 16:04:19 UTC
Created attachment 290585 [details]
redhat-release

Comment 10 Ben Marzinski 2008-01-02 18:22:24 UTC
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 09:42:55 UTC
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.