Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455303 - 64-bit dmeventd vs 32-bit DSO mismatch
Summary: 64-bit dmeventd vs 32-bit DSO mismatch
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: comps
Version: 4.7
Hardware: ppc64
OS: Linux
Target Milestone: rc
: ---
Assignee: Nick Petrov
QA Contact: Alexander Todorov
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-14 19:00 UTC by Nate Straz
Modified: 2009-05-18 20:03 UTC (History)
12 users (show)

Fixed In Version: RHEL 5.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-05-18 20:03:21 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0948 normal SHIPPED_LIVE comps bug fix update 2009-05-18 13:19:58 UTC

Description Nate Straz 2008-07-14 19:00:15 UTC
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

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 dlopen failed: 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

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
Jul 14 13:01:07 basic dmeventd[7078]: dmeventd dlopen failed: 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 
grep 2cd7cabf_e61c_41ec_86c4_1e1f150ab774 /var/log/messages 

Version-Release number of selected component (if applicable):

How reproducible:

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 15:37:55 UTC
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 15:45:16 UTC
Here's the line from lvm.conf:

    snapshot_library = ""

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*/

Comment 3 Petr Rockai 2008-07-15 17:33:02 UTC
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 (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...).


Comment 4 Nate Straz 2008-07-15 17:54:37 UTC
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 23:18:32 UTC
So what gives? Please install ppc64 RPM of lvm2, I have just checked with brew 
that it contains /lib64/ -- 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-16 02:55:49 UTC
Then this is probably a distribution problem because the 64-bit lvm2 packages
are not in the trees.

[nstraz@devserv RPMS]$ pwd
[nstraz@devserv RPMS]$ ls lvm2*
[nstraz@devserv RPMS]$ ls device-mapper*

I'll install the lvm2.ppc64 bits from brew tomorrow and see if that makes a

Comment 7 Milan Broz 2008-07-16 06:41:13 UTC
See bug 369761 - for RHEL5. Too late to do this for RHEL4...

Comment 8 RHEL Product and Program Management 2008-09-05 17:08:00 UTC
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

Comment 9 Petr Rockai 2008-10-06 15:49:56 UTC
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 15:54:14 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Comment 11 Nate Straz 2008-10-06 16:02:27 UTC
How are users supposed to get the lvm2.ppc64 package if it is not released?

Comment 12 Petr Rockai 2008-10-06 16:12:52 UTC
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 08:38:38 UTC
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>


Comment 15 Nick Petrov 2008-10-08 14:42:13 UTC
lvm2 has been added to the ppc64-compat-libs group.

Comment 16 Alexander Todorov 2009-03-02 10:09:21 UTC
VERIFIED lvm2 is in the ppc64-compat-libs group and -0227.1 tree has the following packages:



Comment 18 errata-xmlrpc 2009-05-18 20:03:21 UTC
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.

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