Bug 455303 - 64-bit dmeventd vs 32-bit DSO mismatch
64-bit dmeventd vs 32-bit DSO mismatch
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: comps (Show other bugs)
4.7
ppc64 Linux
medium Severity medium
: rc
: ---
Assigned To: Nick Petrov
Alexander Todorov
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-14 15:00 EDT by Nate Straz
Modified: 2009-05-18 16:03 EDT (History)
12 users (show)

See Also:
Fixed In Version: RHEL 5.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 16:03:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nate Straz 2008-07-14 15:00:15 EDT
Description of problem:

When trying to enable snapshot full warnings on ppc systems I get a bunch of
error messages about dlopen failures instead of warnings that I'm filling the
snapshot.

Test case output:

SCENARIO - [verify_full_snap_warnings]
Making origin volume
Create a snap, almost fill it, and verify lvm warns snap is becoming full
  snapper-2cd7cabf_e61c_41ec_86c4_1e1f150ab774: event registration failed:
7227:3 libdevmapper-event-lvm2snapshot.so dlopen failed:
libdevmapper-event-lvm2snapshot.so: cannot open shared object file: No such file
or directory
  snapper/snapshot0: snapshot segment monitoring function failed.
Fill the snap up past 85%
50000+0 records in
50000+0 records out

Searching syslog for snap is getting full warning
no warning message for snap 2cd7cabf_e61c_41ec_86c4_1e1f150ab774 filling up was
found

Syslog output:

lvcreate -L 4G snapper -n origin 
lvs --noheadings -o lv_attr snapper/origin 
lvcreate -s /dev/snapper/origin -c 32 -n 2cd7cabf_e61c_41ec_86c4_1e1f150ab774 -L
25M 
Jul 14 13:01:07 basic dmeventd[7078]: dmeventd
libdevmapper-event-lvm2snapshot.so dlopen failed:
libdevmapper-event-lvm2snapshot.so: cannot open shared object file: No such file
or directory
lvs --noheadings -o lv_attr snapper/2cd7cabf_e61c_41ec_86c4_1e1f150ab774 
lvs --noheadings -o snap_percent snapper/2cd7cabf_e61c_41ec_86c4_1e1f150ab774 
dmsetup ls 
dd if=/dev/zero of=/dev/snapper/2cd7cabf_e61c_41ec_86c4_1e1f150ab774 count=50000 
sync 
grep 2cd7cabf_e61c_41ec_86c4_1e1f150ab774 /var/log/messages 

Version-Release number of selected component (if applicable):
device-mapper-1.02.25-2.el4.ppc
device-mapper-1.02.25-2.el4.ppc64
lvm2-2.02.37-3.el4.ppc
lvm2-cluster-2.02.37-3.el4.ppc64


How reproducible:
100%

Steps to Reproduce:
See steps above.
  
Actual results:
dlopen errors

Expected results:
A warning message should show up in /var/log/messages


Additional info:
Comment 1 Petr Rockai 2008-07-15 11:37:55 EDT
What is the exact value of dmeventd/snapshot_library, please? Can you confirm 
that the file named there does exist in library search path on the system? 
Might be packaging problem... If the library indeed does exist, can you try 
with listing full path to the library in dmeventd/snapshot_library?

Thank you.
Comment 2 Nate Straz 2008-07-15 11:45:16 EDT
Here's the line from lvm.conf:

    snapshot_library = "libdevmapper-event-lvm2snapshot.so"

We have the 32-bit library, but I'm worried that dmeventd is looking for the
64-bit library.  If I remove device-mapper.ppc64, I can't run dmsetup at all.

# ls /lib*/libdevmapper-event-lvm2snapshot.so
/lib/libdevmapper-event-lvm2snapshot.so
Comment 3 Petr Rockai 2008-07-15 13:33:02 EDT
Oh, that's a mixed setup. Can you check whether your dmeventd binary is 32-bit 
or 64-bit? It'll need the same kind, of course... (You gotta love multiarch.) 
So what you say is, that there's no package containing the 64-bit version of 
libdevmapper-event-lvm2snapshot.so? (I presume the mirror one is in the same 
situation? But indeed, I wouldn't be very surprised if there was no 64-bit 
versions of the libs...).

Thanks.
Comment 4 Nate Straz 2008-07-15 13:54:37 EDT
Yes, dmeventd is 64-bit.

[root@basic ~]# file /sbin/dmeventd
/sbin/dmeventd: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for
GNU/Linux 2.4.19, dynamically linked (uses shared libs), stripped
Comment 5 Petr Rockai 2008-07-15 19:18:32 EDT
So what gives? Please install ppc64 RPM of lvm2, I have just checked with brew 
that it contains /lib64/libdevmapper-event-lvm2snapshot.so -- if that does not 
fix it, then we are in a different kind of trouble.

If it starts to work then, I assume that this is not really a bug, more like 
something to document? (Release notes maybe?) Or is there a sensible way to 
enforce having 64-bit lvm2 libs around on 64-bit/multiarch installs?

(The relationship should roughly be: lvm2(32) installed && dmeventd(64) 
installed -> lvm2(64) installed, lvm2(64) installed && dmeventd(32) 
installed -> lvm2(32) installed... I don't think that's a very sensible way to 
put it, but I'm generally at loss here. Basically the dmeventd's architecture 
dictates which architecture of lvm2 libraries needs to be present (the other 
might be, but that's irrelevant as far as dmeventd goes) -- but dmeventd does 
not depend on those, it is the other way around...)

Oh, I need to sleep instead.
Comment 6 Nate Straz 2008-07-15 22:55:49 EDT
Then this is probably a distribution problem because the 64-bit lvm2 packages
are not in the trees.

[nstraz@devserv RPMS]$ pwd
/mnt/redhat/rel-eng/RHEL4-U7-re20080711.0/tree-AS-ppc/RedHat/RPMS
[nstraz@devserv RPMS]$ ls lvm2*
lvm2-2.02.37-3.el4.ppc.rpm
[nstraz@devserv RPMS]$ ls device-mapper*
device-mapper-1.02.25-2.el4.ppc64.rpm
device-mapper-1.02.25-2.el4.ppc.rpm
device-mapper-multipath-0.4.5-31.el4.ppc.rpm

I'll install the lvm2.ppc64 bits from brew tomorrow and see if that makes a
difference.
Comment 7 Milan Broz 2008-07-16 02:41:13 EDT
See bug 369761 - for RHEL5. Too late to do this for RHEL4...
Comment 8 RHEL Product and Program Management 2008-09-05 13:08:00 EDT
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.
Comment 9 Petr Rockai 2008-10-06 11:49:56 EDT
This has been fixed in RHEL 5.2 by splitting the device-mapper package into two. However, since the abovementioned workaround makes this problem quite easy to fix by installing a missing package and the problem only affects a small number of installations. Therefore, we have decided that this is change is superfluously risky for RHEL 4.8. Users should be advised to install the 64-bit lvm2 package available in RHEL 4.7, which fixes the issue. RHEL 5.2 and later should not be affected.
Comment 10 RHEL Product and Program Management 2008-10-06 11:54:14 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 11 Nate Straz 2008-10-06 12:02:27 EDT
How are users supposed to get the lvm2.ppc64 package if it is not released?
Comment 12 Petr Rockai 2008-10-06 12:12:52 EDT
Oh, right, drat. Sorry. We need to reassign this to someone in release team, as this is not a LVM2 problem in itself, just a problem in building the trees, as the ppc64 binary gets built. I'll try to have releng fix that.
Comment 14 Daniel Mach 2008-10-08 04:38:38 EDT
This should be doable by by adding following record to the ppc64-compat-libs comps group (I don't see any better place for that):
<packagereq type="default">lvm2</packagereq>

DEVEL_ACK+
Comment 15 Nick Petrov 2008-10-08 10:42:13 EDT
lvm2 has been added to the ppc64-compat-libs group.
Comment 16 Alexander Todorov 2009-03-02 05:09:21 EST
VERIFIED lvm2 is in the ppc64-compat-libs group and -0227.1 tree has the following packages:

lvm2-2.02.42-4.el4.ppc64.rpm
lvm2-2.02.42-4.el4.ppc.rpm

device-mapper-1.02.28-2.el4.ppc64.rpm
device-mapper-1.02.28-2.el4.ppc.rpm
device-mapper-multipath-0.4.5-33.el4.ppc.rpm
Comment 18 errata-xmlrpc 2009-05-18 16:03:21 EDT
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.

http://rhn.redhat.com/errata/RHBA-2009-0948.html

Note You need to log in before you can comment on or make changes to this bug.