Description of problem:
The multipath-tools package supports a configuration directive bindings_file to specify an alternate location for the WWID-alias binding database that overrides the default location in /var.
This directive was introduced to address bug 320151 which describes problems seen when this file is located in /var but /var is a separate file system from the root volume (several possible symptoms may be seen depending on timing/configuration).
If a system is using this directive then mkinitrd must make sure to copy the bindings file from the location specified in /etc/multipath.conf to the corresponding relative path inside the initramfs image.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure a multipath boot system with separate /var
2. Edit /etc/multipath.conf specifying e.g.:
/* other stuff */
bindings_file = /etc/multipath/bindings
3. Create the new bindings db or copy over the existing content from /var
4. run mkinitrd
Generated initramfs will contain whatever junk was in /var/lib/multipath/bindings and a configuration file that points to a non-existant bindings_file location.
Generated initramfs contains the file specified by the bindings_file directive at the same relative path within the image.
Created attachment 414927 [details]
determine location of bindings file from multipath.conf and copy to initramfs
Patch from Cedric Buissart to grab location of bindings db from multipath.conf & stuff it into the initrfamfs (with minor typo fixed).
Created attachment 416514 [details]
libbdevid-python for i386
Created attachment 416515 [details]
libbdevid-python for ia64
Created attachment 416516 [details]
libbdevid-python for ppc
Created attachment 416518 [details]
libbdevid-python for ppc64
Created attachment 416519 [details]
libbdevid-python for s390
Created attachment 416521 [details]
libbdevid-python for s390x
Created attachment 416522 [details]
libbdevid-python for x86_64
Created attachment 416523 [details]
mkinitrd for i386
Created attachment 416524 [details]
mkinitrd for ia64
Created attachment 416525 [details]
mkinitrd for ppc
Created attachment 416526 [details]
mkinitrd for ppc64
Created attachment 416527 [details]
mkinitrd for s390
Created attachment 416528 [details]
mkinitrd for s390x
Created attachment 416529 [details]
mkinitrd src rpm
Created attachment 416530 [details]
mkinitrd for x86_64
Created attachment 416531 [details]
mkinitrd-debuginfo for i386
Created attachment 416532 [details]
mkinitrd-debuginfo for ia64
Created attachment 416534 [details]
mkinitrd-debuginfo for ppc
Created attachment 416535 [details]
mkinitrd-debuginfo for ppc64
Created attachment 416536 [details]
mkinitrd-debuginfo for s390
Created attachment 416537 [details]
mkinitrd-debuginfo for s390x
Created attachment 416538 [details]
mkinitrd-debuginfo for x86_64
Created attachment 416539 [details]
mkinitrd-devel for i386
Created attachment 416540 [details]
mkinitrd-devel for ia64
Created attachment 416543 [details]
mkinitrd-devel for ppc
Created attachment 416544 [details]
mkinitrd-devel for ppc64
Created attachment 416546 [details]
mkinitrd-devel for s390
Created attachment 416547 [details]
mkinitrd-devel for s390x
Created attachment 416549 [details]
mkinitrd-devel for x86_64
Created attachment 416550 [details]
nash for i386
Created attachment 416551 [details]
nash for ia64
Created attachment 416552 [details]
nash for ppc
Created attachment 416553 [details]
nash for ppc64
Created attachment 416554 [details]
nash for s390
Created attachment 416555 [details]
nash for s390x
Created attachment 416557 [details]
nash for x86_64
Thanks, next time I'll ask whether or not the receiver has access to brew.
Has the reporter provided test feedback already? Thanks.
Hello GSS folks,
can you help us with testing this fix with the latest 5.6 tree?
With help from Barry Donahue I have the following setup:
/dev/mapper/mpath0p2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/mpath0p3 on /var type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /var/lib/xenstored type tmpfs (rw)
/var is separate partition
# cat /etc/multipath.conf
bindings_file = /etc/multipath/bindings
# Make sure our multipath devices are enabled.
# 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.
# This file was automatically generated by anaconda.
# alias wwid
The configurations is as described in comment #54.
After running mkinitrd on this system the resulting initrd.img contains multipath.conf file and no bindings file at all.
This is with mkinitrd-22.214.171.124-66.el5
Created attachment 468798 [details]
initrd.img from the failed test case
was the test valid? It looks like the issue is not resolved.
Please answer comment #56-#58. Moving back to ASSIGNED until then.
(In reply to comment #58)
> was the test valid? It looks like the issue is not resolved.
I think the bindings_file directive in your multipath.conf file needs to lose the equal sign. Your defaults section should be:
My quick run through the device-mapper-multipath code tells me the equal sign is invalid syntax for that config file. Try it using the above syntax and see if the generated initrd.img works.
device-mapper-multipath package maintainer confirms that the syntax in your multipath.conf file needs to change. The equal sign on the bindings_file line needs to be removed. The rest of the syntax is correct.
I tested the mkinitrd code using your multipath.conf file with the equal sign removed and the correct values are picked up, so I imagine once you run through your test again, the generated initrd.img will be correct.
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.
Previously, mkinitrd did not support the option multipath-tools bindings_file. This update does support this option.
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.
*** Bug 660721 has been marked as a duplicate of this bug. ***