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 674241 - Anaconda should not set the alias of multipath devices to mpath<x>
Summary: Anaconda should not set the alias of multipath devices to mpath<x>
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ales Kozumplik
QA Contact: Gris Ge
URL:
Whiteboard: patch
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-01 06:30 UTC by Ben Marzinski
Modified: 2014-09-30 23:39 UTC (History)
4 users (show)

Fixed In Version: anaconda-13.21.119-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 10:29:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1565 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2011-12-06 00:39:12 UTC

Description Ben Marzinski 2011-02-01 06:30:03 UTC
When anaconda sets up root multipath devices, it seems to always set the alias to mpath<x> in the multipaths section of /etc/multipath.conf.  These names are reserved for user_friendly_names.  While it is safe to do this as long as the same binding exists in /etc/multipath/bindings, users may modify or erase /etc/multipath/bindings, causing conflicts.  For instance, in order to have consistent user_friendly_names across a cluster, users need to copy the bindings file from one machine in the cluster to all the other machines.

If anaconda needs to have a defined name for the root device, it should pick a name that is not of the pattern mpath<x>.

Comment 2 RHEL Program Management 2011-02-01 07:08:45 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 3 RHEL Program Management 2011-02-01 19:13:14 UTC
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

Comment 4 Ales Kozumplik 2011-02-21 13:07:30 UTC
(In reply to comment #0)
> When anaconda sets up root multipath devices, it seems to always set the alias
> to mpath<x> in the multipaths section of /etc/multipath.conf.  These names are
> reserved for user_friendly_names.  While it is safe to do this as long as the
> same binding exists in /etc/multipath/bindings, users may modify or erase
> /etc/multipath/bindings, causing conflicts.  For instance, in order to have
> consistent user_friendly_names across a cluster, users need to copy the
> bindings file from one machine in the cluster to all the other machines.
> 
> If anaconda needs to have a defined name for the root device, it should pick a
> name that is not of the pattern mpath<x>.

Ben,

should I be fixing this? Some users might depend on the existing alieases and this would break backward compatibility..

Thanks.

Comment 5 Ben Marzinski 2011-02-21 19:22:25 UTC
As long as this is only getting changed on new installations, I don't see how this could break anything.  Am I missing something?

Comment 6 Ales Kozumplik 2011-06-02 14:07:34 UTC
Ben,

I am going to fix this by not giving an alias to any multipath devices and not creating the bindings file either (multipath creates one automatically). Please let me know if this is okay from multipath's point of view (i.e. the devices will be properly assembled and we will not recreate bug 640735).

This also assumes that once we write out multipath.conf (now without the aliases) that multipath tools will not rename any device. Anaconda wouldn't be able to handle that. Is this assumption correct?

Thank you.

Comment 7 RHEL Program Management 2011-06-02 14:20:28 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Comment 8 Ben Marzinski 2011-06-02 17:39:01 UTC
Not creating any alias and not writing out the bindings file should work fine.  If you have user_friendly_names set in /etc/multipath.conf, and you run multipath without the -B option, it will create a bindings file all by itself. Once this is set, the device will continue to use that name unless the user manually edits the bindings file, which they are not supposed to do in regular situations. However, because multipath has to be available in early boot, there is a bindings file in the initramfs as well. As long as dracut gets run after multipath creates its bindings file, it should pull the current /etc/multipath.conf file into the initramfs, which will guarantee that multipath uses the same name for the device if it is created in early boot.

Comment 9 Ales Kozumplik 2011-06-03 11:37:58 UTC
Patch is awaiting review:

https://www.redhat.com/archives/anaconda-devel-list/2011-June/msg00029.html

Comment 12 Ales Kozumplik 2011-06-17 08:13:40 UTC
Fixed on the rhel6 branch by commit b46a086d2881b61a41b123bc1a0cfac5a83f32a4.

Comment 15 Gris Ge 2011-08-26 07:47:24 UTC
Ales:

I am a little bit confuse about this thing.

Here is test results:
=========
Repo: RHEL6.2-20110823.1
OS install with "ondisk=/dev/disk/by-id/dm-uuid-mpath-<WWID>" options.

OS boot up with inconsistent name, but works well.

No alias in /etc/multipath.conf in OS

No "/etc/multipath/wwids" in initramfs
=========
I believe running dracut after boot up will fix this issue (not tested).

For the path name still inconsistent, why we do this:

1. Anaconda use multipath to generate "bindings" and store then into both initramfs and OS
1. If user need to change mpath name by copy binding file from other server, they need to run dracut after that.

If I miss anything, correct me. Thanks.

Comment 16 Ales Kozumplik 2011-08-26 07:56:55 UTC
The only solution I can see is the one I mention in https://bugzilla.redhat.com/show_bug.cgi?id=701371#c49. Let's wait for Ben's opinion and then either leave this as it is (because Ben confirmed it is not really a problem) or fix as I propose for 6.3.

Comment 17 Ben Marzinski 2011-08-26 17:44:41 UTC
Ales, Your solution is fine, but I think it amounts to the same thing as Gris's. If you run multipath with user_friendly_names set, it will create

/etc/multipath/bindings

If it is not set, then multipath won't.  Or did you mean that you want anaconda
to manually create the bindings file so that you can be sure of the name without having to parse the multipath created file?  If so, it's a simple format, so there
shouldn't be any problem with you doing that either.

Comment 18 Gris Ge 2011-08-29 03:14:17 UTC
Ben,
Just a correction, if mount point name is different from current mpath name, it __DO__ harm OS: multipathd can be stopped without any warning even OS is boot from SAN.

I will request blocker for this bug.

Comment 19 Ales Kozumplik 2011-08-29 12:54:38 UTC
(In reply to comment #18)
> Ben,
> Just a correction, if mount point name is different from current mpath name, it
> __DO__ harm OS: multipathd can be stopped without any warning even OS is boot
> from SAN.
> 
> I will request blocker for this bug.

I think that the mount device problem is a completely different bug and I am not sure what I outlined in https://bugzilla.redhat.com/show_bug.cgi?id=701371#c49 will work for that. Moving back to modified.

Please open a new bug and lend me a storageqe machine with multipath and I'll take a look.

Comment 20 Ales Kozumplik 2011-08-29 12:59:32 UTC
(In reply to comment #17)

> If it is not set, then multipath won't.  Or did you mean that you want anaconda
> to manually create the bindings file so that you can be sure of the name
> without having to parse the multipath created file?  If so, it's a simple
> format, so there
> shouldn't be any problem with you doing that either.

Yeah that's what I meant. Let's see if that helps.

Comment 21 Gris Ge 2011-08-30 09:11:35 UTC
Bug 734374 as you requested and storageqe-05 loaned to you.

For https://bugzilla.redhat.com/show_bug.cgi?id=701371#c49 , how about this way:

1. User specify mpatha in kickstart, we create binding file both in initramfs and OS.
2. User specify wwid path in kickstart, we set "user_friendly_names no" in /etc/multipath.conf of OS. So that OS boot up with /dev/mapper/<WWID> path for multipath.

Both of them will not create alias in /etc/multipath.conf which allow user to spread their binding file.

I will verify this bug once it's back to ON_QA. Future update please goes to Bug 734374.

Thanks for your great work.

Comment 23 Gris Ge 2011-09-19 02:37:25 UTC
As comments above, VERIFY

Comment 24 errata-xmlrpc 2011-12-06 10:29:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1565.html


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