touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #61056
[Bug 1088081] Re: udev rules make it impossible to deactivate lvm volume group with vgchange -an
Has this ever truly been resolved? I believe I am seeing this same bug
with 14.04 and failing to resolve it even with the workarounds listed
here. After unstack I'm left with a logical volume which I cannot delete
or deactivate.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1088081
Title:
udev rules make it impossible to deactivate lvm volume group with
vgchange -an
Status in lvm2 package in Ubuntu:
Confirmed
Status in udev package in Ubuntu:
Confirmed
Bug description:
Running 'vgchange -a n volume_group_name' generates udev events that are matched by /lib/udev/rules.d/85-lvm2.rules, causing it to run 'vgchange -a y'. This defeats the initial 'vgchange -a n' and makes it impossible to:
* run 'cryptsetup luksClose' on the underlying encrypted device
* safely remove a removable drive containing an LVM physical volume
* safely use dd to copy the LVM partition to another device (LVM might be writing data)
I turned up logging and it looks like the following happened to the instance I was watching:
1. 'vgchange -a n vgname' caused LVM to close /dev/dm-5 (the LUKS dm device holding the LVM physical volume)
2. udev logged this: device /dev/dm-5 closed, synthesising 'change'
3. a new 'change' 'block' udev event was enqueued for the LUKS dm device
4. udev started processing the new 'change' event
5. the event matched /lib/udev/rules.d/60-persistent-storage-dm.rules:16 so blkid was run and set ID_FS_TYPE=LVM2_member
6. all of the conditions for /lib/udev/rules.d/85-lvm2.rules matched, so 'vgchange -a y' was run
Brainstorming ideas for fixing this:
* I'm not sure why udev synthesizes a change event when a dm device is closed, but disabling that bit of code should fix this bug (and probably cause many worse bugs).
* Maybe the lvm udev rule should condition on ACTION=="add" instead of ACTION="add|change" (just tried this and unfortunately it doesn't work -- unlocking a LUKS device causes two back-to-back udev events: one 'add' event that only appears to match /lib/udev/rules.d/50-udev-default.rules:67 and a second 'change' event that matches much more).
Other info:
$ lsb_release -rdc
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal
lvm2 version: 2.02.95-4ubuntu1
udev version: 175-0ubuntu13
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081/+subscriptions