19cc447
commit 764195207d4773cf6f1674a2fb16e9a0acda304a
19cc447
Author: Peter Rajnoha <prajnoha@redhat.com>
19cc447
Date:   Fri Apr 19 12:17:53 2013 +0200
19cc447
19cc447
    udev: also autoactivate on coldplug
19cc447
    
19cc447
    Commit 756bcabbfe297688ba240a880bc2b55265ad33f0 fixed autoactivation
19cc447
    to not trigger on each uevent for a PV that appeared in the system
19cc447
    most notably the events that are triggered artificially (udevadm
19cc447
    trigger or as the result of the WATCH udev rule being applied that
19cc447
    consequently generates CHANGE uevents). This fixed a situation in
19cc447
    which VGs/LVs were activated when they should not.
19cc447
    
19cc447
    BUT we still need to care about the coldplug used at boot to
19cc447
    retrigger the ADD events - the "udevadm trigger --action=add"!
19cc447
    
19cc447
    For non-DM-based PVs, this is already covered as for these we
19cc447
    run the autoactivation on ADD event only.
19cc447
    
19cc447
    However, for DM-based PVs, we still need to run the
19cc447
    autoactivation even for the artificial ADD event, reusing
19cc447
    the udev DB content from previous proper CHANGE event that
19cc447
    came with the DM device activation.
19cc447
    
19cc447
    Simply, this patch fixes a situation in which we run extra
19cc447
    "udevadm trigger --action=add" (or echo add > /sys/block/<dev>/uevent)
19cc447
    for DM-based PVs (cryptsetup devices, multipath devices, any
19cc447
    other DM devices...).
19cc447
    
19cc447
    Without this patch, while using lvmetad + autoactivation,
19cc447
    any VG/LV that has a DM-based PV and for which we do not
19cc447
    call the activation directly, the VG/LV is not activated.
19cc447
    
19cc447
    For example a VG with an LV with root FS on it which is directly
19cc447
    activated in initrd and then missing activation of the rest
19cc447
    of the LVs in the VG because of unhandled uevent retrigger on
19cc447
    boot after switching to root FS (the "coldplug").
19cc447
    
19cc447
    (No WHATS_NEW here as this fixes the commit mentioned
19cc447
    above and which was not released yet.)
19cc447
---
19cc447
 udev/10-dm.rules.in           | 5 ++++-
19cc447
 udev/69-dm-lvm-metad.rules.in | 1 +
19cc447
 2 files changed, 5 insertions(+), 1 deletion(-)
19cc447
19cc447
diff --git a/udev/10-dm.rules.in b/udev/10-dm.rules.in
19cc447
index cfee145..512d156 100644
19cc447
--- a/udev/10-dm.rules.in
19cc447
+++ b/udev/10-dm.rules.in
19cc447
@@ -77,7 +77,10 @@ LABEL="dm_flags_done"
19cc447
 # before (e.g. in initrd). If udev is used in initrd, we require the udev init
19cc447
 # script to not remove the existing udev database so we can reuse the information
19cc447
 # stored at the time of device activation in the initrd.
19cc447
-ACTION=="add", ENV{DM_UDEV_RULES_VSN}!="1", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable"
19cc447
+ACTION!="add", GOTO="dm_no_coldplug"
19cc447
+ENV{DM_UDEV_RULES_VSN}!="1", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable"
19cc447
+ENV{DM_ACTIVATION}="1"
19cc447
+LABEL="dm_no_coldplug"
19cc447
 
19cc447
 # "dm" sysfs subdirectory is available in newer versions of DM
19cc447
 # only (kernels >= 2.6.29). We have to check for its existence
19cc447
diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in
19cc447
index b16a27a..66c58b3 100644
19cc447
--- a/udev/69-dm-lvm-metad.rules.in
19cc447
+++ b/udev/69-dm-lvm-metad.rules.in
19cc447
@@ -26,6 +26,7 @@ ACTION=="remove", GOTO="lvm_scan"
19cc447
 KERNEL!="dm-[0-9]*", ACTION!="add", GOTO="lvm_end"
19cc447
 
19cc447
 # If the PV is a dm device, scan only after proper mapping activation (CHANGE event + DM_ACTIVATION=1)
19cc447
+# or after a coldplug (event retrigger) with "add" event (ADD event + DM_ACTIVATION=1)
19cc447
 KERNEL=="dm-[0-9]*", ENV{DM_ACTIVATION}!="1", GOTO="lvm_end"
19cc447
 
19cc447
 LABEL="lvm_scan"