Description of problem: /sbin/multipath.static is dynamically linked instead of being statically. I noticed this after a libsysfs.so not such file or directory error was issued at boot time (libsysfs resides in /usr/lib, and while still in initrd /usr is not yet mounted). Version-Release number of selected component (if applicable): bash# rpm -qf /sbin/multipath.static device-mapper-multipath-0.4.7-15.fc9.i386 How reproducible: Always: ldd /sbin/multipath.static linux-gate.so.1 => (0x0012e000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x0012f000) libsysfs.so.2 => /usr/lib/libsysfs.so.2 (0x00146000) libc.so.6 => /lib/libc.so.6 (0x00152000) libselinux.so.1 => /lib/libselinux.so.1 (0x002bb000) libsepol.so.1 => /lib/libsepol.so.1 (0x002d7000) /lib/ld-linux.so.2 (0x00110000) libdl.so.2 => /lib/libdl.so.2 (0x00311000) bash# rpm -qf /sbin/multipath.static device-mapper-multipath-0.4.7-15.fc9.i386 Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: I'm not sure how serious is this so I'll leave the severity to "low". Maybe there are people who are really using devices that require multipath and because of this issue they are not able to boot.
We don't include static binaries any more (initrd doesn't need them now), but the .static might be there for compatibility reasons till scripts stop referring to it. libsysfs may need to be in /lib* though if /usr is a separate mount point and the binary is used by initscripts before it's mounted. [check this & open new bz if necessary]
multipath.static seems to be called in rc.sysinit before the rest of the filesystems are mounted, and indeed it is not called in initrd (I just checked this, so I'm sorry for my previous statement about it being called from initrd).
Alasdair is correct, the issue is that libsysfs is in /usr instead of /lib, which may not be mounted when multipath is called. A multipath bug for this was already opened (451415) and fixed in device-mapper-multipath-0.4.7-16.fc9 which now works around the problem by statically linking to just libsysfs. However, this is a workaround, and a bug should be opened against libsysfs to move it into /lib if possible.
*** This bug has been marked as a duplicate of 451415 ***