Bug 451415

Summary: multipath linked again /usr/lib64/libsysfs.so.2 which is not available at boot
Product: [Fedora] Fedora Reporter: Joachim Frieben <jfrieben>
Component: device-mapper-multipathAssignee: Ben Marzinski <bmarzins>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: agk, billcrawford1970, bmarzins, dwysocha, jbnance, kdiegorsantos, lsmituc, mbroz, packages, prockai
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: device-mapper-multipath-0.4.7-16.fc9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-24 15:28:48 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 Joachim Frieben 2008-06-14 10:16:10 UTC 
Description of problem:
Whenn booting up a current F9 system, /sbin/multipath.static complains
about a missing library libsysfs.so.2.

Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.7-15.fc9.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Boot current F9 system.
  
Actual results:
Error message appears about a missing libsysfs.so.2 library.

Expected results:
Boot procedure performs without error message.

Additional info:
ldd /sbin/multipath returns

 linux-vdso.so.1 =>  (0x00007fff441fe000)
 libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00000034f3a00000)
 libsysfs.so.2 => /usr/lib64/libsysfs.so.2 (0x00000034b1a00000)
 libc.so.6 => /lib64/libc.so.6 (0x00000034f4000000)
 libselinux.so.1 => /lib64/libselinux.so.1 (0x00000034f5400000)
 libsepol.so.1 => /lib64/libsepol.so.1 (0x00000034f3600000)
 /lib64/ld-linux-x86-64.so.2 (0x00000034f2e00000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00000034f4800000)

Thus libsysfs.so.2 is present but located in /usr/lib64/ which is probably
not mounted yet when libsysfs.so.2 is requested. It should be located in
/lib64, right?

Btw, linux-vdso.so.1 does not even exist but that is a different bug!
Comment 1 Bill Crawford 2008-06-14 10:51:45 UTC 
Fairly good argument against making everything dynamic in itself (although it's
almost impossible to have a read-only /usr now what with texlive using
/usr/share/texmf-var instead of something in /var ...).
Comment 2 Jeroen Beerstra 2008-06-16 21:00:17 UTC 
just a quick me2
Comment 3 Ian Chapman 2008-06-22 00:48:18 UTC 
For the record it's not just x86_64 but at least ppc32 also:

$ ldd /sbin/multipath.static

linux-vdso32.so.1 =>  (0x00100000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x0fa00000)
libsysfs.so.2 => /usr/lib/libsysfs.so.2 (0x0fde0000)
libc.so.6 => /lib/libc.so.6 (0x0fe00000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0ef60000)
libsepol.so.1 => /lib/libsepol.so.1 (0x0fa30000)
/lib/ld.so.1 (0x0ffb0000)
libdl.so.2 => /lib/libdl.so.2 (0x0fcf0000)
Comment 4 Fedora Update System 2008-06-23 22:08:16 UTC 
device-mapper-multipath-0.4.7-16.fc9 has been submitted as an update for Fedora 9
Comment 5 Victor Chukhantsev 2008-06-24 00:24:08 UTC 
duplicate bug: https://bugzilla.redhat.com/show_bug.cgi?id=452423
Comment 6 Dave Wysochanski 2008-06-24 03:29:42 UTC 
*** Bug 452423 has been marked as a duplicate of this bug. ***
Comment 7 Ben Marzinski 2008-07-21 16:23:32 UTC 
*** Bug 455962 has been marked as a duplicate of this bug. ***
Comment 8 Diego R. Santos 2015-04-21 08:21:40 UTC 
cp /usr/lib64/libsysfs.so.2.0.1 /lib64/
ln -s /lib64/libsysfs.so.2.0.1 /lib64/libsysfs.so.2