Bug 622385 - Can't update lvm2 from updates-testing
Summary: Can't update lvm2 from updates-testing
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2   
(Show other bugs)
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Dave Wysochanski
QA Contact: Fedora Extras Quality Assurance
: 622810 622816 (view as bug list)
Depends On:
Blocks: 610889
TreeView+ depends on / blocked
Reported: 2010-08-09 07:27 UTC by Frank Murphy
Modified: 2010-12-13 14:57 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-13 14:57:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Frank Murphy 2010-08-09 07:27:32 UTC
Description of problem: can't update lvm2 due to udisks? needing lower version.

sudo yum update
[sudo] password for xxxx
Loaded plugins: auto-update-debuginfo, downloadonly, fastestmirror, langpacks, local, presto, protectbase, refresh-packagekit, remove-with-
              : leaves, security
Adding en_IE to language list
Loading mirror speeds from cached hostfile
 * fedora: mirror.sov.uk.goscomb.net
 * updates: mirror.ox.ac.uk
 * updates-testing: mirror.ox.ac.uk
0 packages excluded due to repository protections
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package lvm2.x86_64 0:2.02.72-4.fc13 set to be updated
--> Processing Dependency: liblvm2app.so.2.1()(64bit) for package: udisks-1.0.1-1.fc13.x86_64
--> Processing Dependency: liblvm2app.so.2.1(Base)(64bit) for package: udisks-1.0.1-1.fc13.x86_64
---> Package lvm2-libs.x86_64 0:2.02.72-4.fc13 set to be updated
--> Finished Dependency Resolution
--> Running transaction check
---> Package lvm2-libs.x86_64 0:2.02.72-4.fc13 set to be updated
--> Processing Dependency: lvm2-libs = 2.02.72-4.fc13 for package: lvm2-2.02.72-4.fc13.x86_64
--> Finished Dependency Resolution

Packages skipped because of dependency problems:
    lvm2-2.02.72-4.fc13.x86_64 from updates-testing
    lvm2-libs-2.02.72-4.fc13.x86_64 from updates-testing

Comment 1 Milan Broz 2010-08-09 11:10:47 UTC
grrrrr. lvm2app API/ABI changed.

two possible solutions
- revert abi change in lvm2app
- upgrade also udisks in F13 (which is only user of it)

Comment 2 Milan Broz 2010-08-09 11:25:50 UTC
David, is it possible to rebuild udisks in F13 with the lvm2app patch from rawhide?

This lvm2 update fixes also https://bugzilla.redhat.com/CVE-2010-2526 so we should try to push update asap - and udisks rebuild seems to be easy (and it is already built for F14).

Comment 3 Dave Wysochanski 2010-08-09 19:04:20 UTC
Waiting for rebuild of udisks per email conversation with David Zeuthen.

Comment 4 David Zeuthen 2010-08-09 20:01:37 UTC
OK, I've committed the patch on f13/master


along with other changes (autoreconf, added BRs etc.). However, since the latest lvm2 packages are not in buildroot, the build fails with the expected error

 configure: error: lvm2 support requested but libraries not found

since we want lvmapp >= 2.2 (pkgconfig version). See


for more information.

To resolve this, please ask releng to put your latest lvm2 packages in the buildroot and then rebuild udisks. Thanks.

Comment 5 Dave Wysochanski 2010-08-09 20:10:34 UTC
Ok - will do.  Thanks for the update David!

Comment 6 Milan Broz 2010-08-10 13:36:01 UTC
*** Bug 622810 has been marked as a duplicate of this bug. ***

Comment 7 Milan Broz 2010-08-10 13:41:15 UTC
*** Bug 622816 has been marked as a duplicate of this bug. ***

Comment 8 Dave Wysochanski 2010-08-10 19:25:13 UTC
Still not there yet but making progress.  I filed this releng ticket and Bill Nottingham worked on it: https://fedorahosted.org/rel-eng/ticket/3946

I resubmitted the udisks build in koji but now it is failing because of a udev dependency on device mapper.  So I guess I need another releng ticket - having issues getting to koji / fedroahosted though at the moment - not sure what is going on.

Comment 9 Dave Wysochanski 2010-08-10 20:51:17 UTC
Ok new udisks build is now green, after Bill taggged new udev as well.  Task id in koji was 2392140.  This issue should be resolved though I'm told there may be another issue related to udev / lvm2 that peter (prajnoha) is investigating.  We need to push lvm2, dm, udev, and udisks all as one update.

Comment 10 Peter Rajnoha 2010-08-11 09:44:30 UTC

Unfortunately, I've just found a very annoying bug in dm udev rules. It's related to a recent change where we make use of DM_UDEV_PRIMARY_SOURCE_FLAG to help support synthesized events (just like the one used at boot when calling "udevadm trigger --action=add" in udev init script).

Having *old* dm rules+libdevmapper in initrd and having *new* dm rules+libdevmapper used in the system itself after pivot root causes problems. The DM_UDEV_PRIMARY_SOURCE_FLAG is not stored in udev db from initrd and so we can't identify the synthesized ADD events generated by udev init script. We try to ignore any spurious ADD events (except the ones where DM_UDEV_PRIMARY_SOURCE_FLAG is in udev db already and so we know the device has already been activated properly before). But without that flag and ignoring the event results in the symlinks for those devices to be removed... rc.sysinit script the can't find the symlinks and so it fails.

I'll try to come up with a fix for this.

(the obvious fix is to rebuild the initrd so new udev rules+libdevmapper will get there, but it I can't expect that to happen, of course...)

Please, wait with the update!

Comment 11 Peter Rajnoha 2010-08-12 16:02:59 UTC
I fixed the rules so there shouldn't be a problem with combining old and new libdevmapper/udev rules in initrd and system itself now:


We need to attach this patch to the lvm2 build...

Comment 12 Milan Broz 2010-08-17 11:16:32 UTC
Dave, how it is with that update?

I think compatibility patch is ready.

Comment 13 Frank Murphy 2010-09-29 07:36:25 UTC
Sorry very late reply.  My F13 boxes are sorted

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