diff options
| author | Peter Rajnoha <prajnoha@redhat.com> | 2013-08-16 15:45:00 +0200 |
|---|---|---|
| committer | Peter Rajnoha <prajnoha@redhat.com> | 2013-08-16 15:45:00 +0200 |
| commit | cac49725c9a2a1f5c0e48235a07f168d98458ace (patch) | |
| tree | c330c9ceed1faca2cf6bc20523c6551fff45493e /udev | |
| parent | f1dc4d3d81456d506b2c56fb2e8b12106cbd9e16 (diff) | |
| download | lvm2-cac49725c9a2a1f5c0e48235a07f168d98458ace.tar.gz | |
udev: fix lvmetad rules to not ignore loop device configuration
If loop device is first configured on systems where /dev/loop-control
is used to dynamically create the loop device itself, there's an
ADD+CHANGE even generated. But next time the existing /dev/loop[0-9]*
is reused, there's only a CHANGE event since the device representing
it is already present in kernel (so no ADD event in this case).
We can't ignore this CHANGE event for loop devices! This is a regression
caused by 756bcabbfe297688ba240a880bc2b55265ad33f0. We already had
a similar problem with MD devices which was fixed by
2ac217d408470dcecb69b83d9cbf7a254747fa5b (but that one was
only an intra-release fix).
Diffstat (limited to 'udev')
| -rw-r--r-- | udev/69-dm-lvm-metad.rules.in | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in index a0e48a1b1..d5087e3a4 100644 --- a/udev/69-dm-lvm-metad.rules.in +++ b/udev/69-dm-lvm-metad.rules.in @@ -21,7 +21,7 @@ SUBSYSTEM!="block", GOTO="lvm_end" ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member", GOTO="lvm_end" ACTION=="remove", GOTO="lvm_scan" -ACTION=="change", KERNEL=="md[0-9]*", GOTO="lvm_scan" +ACTION=="change", KERNEL=="md[0-9]*|loop[0-9]*", GOTO="lvm_scan" # If the PV is not a dm device, scan only after device addition (ADD event) KERNEL!="dm-[0-9]*", ACTION!="add", GOTO="lvm_end" |