← Back to team overview

touch-packages team mailing list archive

[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