I also see this race condition happen often when I open up and manipulate nested LVM devices.
For example, an LV is partitioned and one of the partitions inside is a PV. A kpartx -a is run to activate the partitions, vgimportclone is run to rename the VG inside that nested PV, and as MatthewParslow said above the old nested VG device nodes are always left behind. After cleaning those up manually, a sequence of two commands is run, vgchange -a n on the renamed VG and kpartx -d on the top-level LV. It usually works (it wins the race with udev vgchange -a y), but sometimes it doesn't. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
