Bug 674241
Summary: | Anaconda should not set the alias of multipath devices to mpath<x> | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Ben Marzinski <bmarzins> |
Component: | anaconda | Assignee: | Ales Kozumplik <akozumpl> |
Status: | CLOSED ERRATA | QA Contact: | Gris Ge <fge> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.0 | CC: | czhang, fge, jzeleny, mbanas |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | patch | ||
Fixed In Version: | anaconda-13.21.119-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-12-06 10:29:50 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ben Marzinski
2011-02-01 06:30:03 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. 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. (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. As long as this is only getting changed on new installations, I don't see how this could break anything. Am I missing something? 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. 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. 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. Patch is awaiting review: https://www.redhat.com/archives/anaconda-devel-list/2011-June/msg00029.html Fixed on the rhel6 branch by commit b46a086d2881b61a41b123bc1a0cfac5a83f32a4. 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. 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. 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. 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. (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. (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. 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. As comments above, VERIFY 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 |