Description of problem: On systems with a separate /var filesystem, it is a well known fact that the multipath bindings file must be relocated from /var/lib/multipath/bindings to a location directly off of / to avoid certain timing issues that may arise from /var not being mounted early enough in boot when the bindings file is first referenced. This is easily solved via the config directive "bindings_file" in /etc/multipath.conf. This fixes the issue in most cases, however, in a boot from mpath environment, it is possible to wind up in a situation where this is not the full solution. Currently mkinitrd sources the bindings file from a static location of /var/lib/multipath/bindings, and I feel this is incorrect and needs some logic to determine the proper file to pull in. Otherwise, it is possible to have a multipath.conf in your initrd that references /etc/multipath_bindings (for instance), but not have this file present in the image, and instead include a "dead" /var/lib/multipath/bindings file that is not being referenced at all. Version-Release number of selected component (if applicable): [root@mysqlrtpa01 ~]# mkinitrd --version mkinitrd: version 5.1.19.6 [root@mysqlrtpa01 ~]# rpm -q mkinitrd mkinitrd-5.1.19.6-61 mkinitrd-5.1.19.6-61 [root@mysqlrtpa01 ~]# How reproducible: Every time. Steps to Reproduce: 1. install a boot from mpath system 2. set up a separate /var mount point 3. move multipath bindings file as required in this setup with the bindings_file directive in /etc/multipath.conf to move the file to /etc/multipath_bindings 4. rebuild initrd 5. examine newly built initrd Actual results: The initrd contains a multipath.conf that says "bindings_file /etc/multipath_bindings" but does not contain the file /etc/multipath_bindings. Instead, it contains the file /var/lib/multipath/bindings Expected results: The mkinitrd script should parse the config for the proper bindings file and include it in the initrd image. Additional info: It is interesting to note that despite this being an obvious flaw, that more people have not hit it and complained about it with boot from mpath becoming more and more popular. I believe this is because the situation where this bug negatively impacting users (as opposed to simply being present, but transparent) isn't quite as typical of a config. When your boot/root lun is mpath0, as is the most typically configured case, I don't think this bug is likely to burn you. However, if your boot/root is bound to a name other than mpath0 is when things get interesting and start to break because of this.
My first attempt for a patch that addresses this looks like this: <snip> diff -up ./mkinitrd.ORIG ./mkinitrd --- ./mkinitrd.ORIG 2010-12-01 12:09:09.210645000 -0500 +++ ./mkinitrd 2010-12-07 11:51:30.670824000 -0500 @@ -1606,8 +1606,12 @@ if [ "$use_multipath" == "1" ]; then if [ -f /etc/multipath.conf ]; then inst /etc/multipath.conf $MNTIMAGE/etc/multipath.conf fi - if [ -f /var/lib/multipath/bindings ]; then - inst /var/lib/multipath/bindings $MNTIMAGE/var/lib/multipath/bindings + mpathbindings=`grep bindings_file /etc/multipath.conf | grep -v ^# | awk '{print $2}'` + if [ "$mpathbindings" = "" ]; then + mpathbindings=`echo "/var/lib/multipath/bindings"` + fi + if [ -f $mpathbindings ]; then + inst $mpathbindings $MNTIMAGE/$mpathbindings fi inst /sbin/scsi_id $MNTIMAGE/bin/scsi_id inst /etc/scsi_id.config $MNTIMAGE/etc/scsi_id.config <snip> I'll add it as an attachment as well. Note that I have some internal debate over the best way to accomplish this, so this is only a first attempt. Trying to parse the config directive out of the config file and then falling back to the default location seems the "safest" way, at first glance. It would also be possible to query the multipathd daemon for the current running config and get the parameter that way via something like: mpathbindings=`echo "show config" | multipathd -k | grep bindings_file | awk '{print $2}'` instead, however, this obviously doesn't function well when multipathd isn't running. I'd generally argue that situation is a misconfiguration, however, in situations like rescue mode the waters get muddied a bit. I'd welcome any other input or ideas here as well.
Created attachment 465272 [details] First attempt at patch to make mkinitrd parse bindings_file config directive instead of simply using a static location.
It appears this was resolved in: http://rhn.redhat.com/errata/RHBA-2010-0541.html https://bugzilla.redhat.com/show_bug.cgi?id=596134 (5.5.z) https://bugzilla.redhat.com/show_bug.cgi?id=593050 (5.6)
*** This bug has been marked as a duplicate of bug 593050 ***