As the errors show, at the end, this just means that snapshot usage monitoring isn't started properly.  lvm2 starts monitoring snapshots when they are activated.  If lvm2 can load the dmeventd snapshot library (because it doesn't exist) the monitoring fails to start.

The library isn't found because dracut has not been trained to include libdevmapper-event-lvm2snapshot.so in the initramfs.

So not only should dracut add dm-snapshot.ko (if CONFIG_DM_SNAPSHOT=m) it should also be adding the dmeventd snapshot library.

(In reply to comment #1)
> As the errors show, at the end, this just means that snapshot usage monitoring
> isn't started properly.  lvm2 starts monitoring snapshots when they are
> activated.  If lvm2 can load the dmeventd snapshot library (because it doesn't
> exist) the monitoring fails to start.

That obviously should've read: "If lvm2 cannot load ..."

Or rather:

dracut should use --monitor n on lv/vgchange, which should avoid the messages without needing to change anything else;

and

initscripts should start up monitoring on already-active LVs using lvchange --monitor -y

FYI, platform is x86_64 and the i686 flavor of those libs aren't installed.

(In reply to comment #3)
> Or rather:
> 
> dracut should use --monitor n on lv/vgchange, which should avoid the messages
> without needing to change anything else;
> 
> and
> 
> initscripts should start up monitoring on already-active LVs using lvchange
> --monitor -y  

OK, so dracut's modules.d/90lvm/lvm_scan.sh should switch to using:
lvm vgchange -ay --monitor n ...

And lvm2's lvm2-monitor initscript already starts monitoring all active LVs with:
$VGCHANGE --monitor y $vg


But after some root FS snapshot-merge testing it seems that lvm2's polldaemon-based progress monitoring should also be controlled via --monitor.  Otherwise, vgchange -ay will fork the polldaemon for mirror (PVMOVE) or  snapshot-merge LVs.

It appears that the lvm2 polldaemon(s), e.g. for the root FS in the case of snapshot-merge, could still be running at the time of the initramfs' pivot.  lvm2 really should not be starting the polldaemon(s) from within the initramfs.  But they'll need to be started via the lvm2-monitor initscript.

So this begs the question: should --monitor be overloaded to also control lvm2's polldaemon-based monitoring?  I believe it should.

dracut-003-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dracut-003-1.fc12

dracut-003-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dracut'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12432

Created attachment 375076 [details]
dracut should only use lvm with read-only locking

dracut-003-1.fc12 adds '--monitor n' like was discussed.  But this only fixes a symptom of the larger problem.  After further review of how lvm is used by dracut (and the read-write /var that the initramfs provides): initramfs should not allow lvm the potential to effect _any_ LVM VG metadata changes.  Using lvm's readonly locking will prevent any lvm metadata changes (and will also prevent dmeventd monitoring from being started).

Setting back to "assigned".  Changing subject from "dmeventd errors with snapshots".

dracut needs a more complete fix for how it uses lvm.

(In reply to comment #8)
> Using lvm's readonly locking will prevent any lvm metadata changes (and will
> also prevent dmeventd monitoring from being started).  

just FYI: read-only locking does _not_ prevent dmeventd monitoring from starting.

This problem also arises with LVM2 mirror logical volumes.

bumping priority to reflect understanding that has been reached with dracut team (pknirsch specifically).

dracut-004-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dracut-004-4.fc12

dracut-004-4.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dracut'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1088

dracut-004-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.