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:
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.
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
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.
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
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.
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.
See bug 369761 - for RHEL5. Too late to do this for RHEL4...
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.
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.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
How are users supposed to get the lvm2.ppc64 package if it is not released?
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.
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+
lvm2 has been added to the ppc64-compat-libs group.
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
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