Bug#467090: lvm-common: Snapshotting LVM1 volumes with LVM2 tools corrupts volume group

[Dominic Hargreaves]

Package: lvm-common
Version: 1.5.20
Severity: critical
Justification: causes serious data loss

When run on a system with LVM1 format volume groups, lvcreate caused the
volume group in question to become inaccessible after reboot.

callisto:~# lvcreate -L 1G -s -n home-snap /dev/sys_vg/home 
  Invalid LV in extent map (PV /dev/hda7, PE 1792, LV 4, LE 0)
  Couldn't fill logical volume maps.
  Invalid LV in extent map (PV /dev/hda7, PE 1792, LV 4, LE 0)
  Couldn't fill logical volume maps.
  Invalid LV in extent map (PV /dev/hda7, PE 1792, LV 4, LE 0)
  Couldn't fill logical volume maps.
  Invalid LV in extent map (PV /dev/hda7, PE 1792, LV 4, LE 0)
  Couldn't fill logical volume maps.
  Volume group for uuid not found: nZRTujLB1Ylthf1wIXjCzcYb6t18VwW300000000000000000000000000000003
  Failed to suspend origin home

dom at callisto:~$ sudo vgdisplay
  --- Volume group ---
  VG Name               big_vg
  System ID             callisto1107014873
  Format                lvm1
  VG Access             read/write
  VG Status             resizable
  MAX LV                256
  Cur LV                1
  Open LV               1
  Max PV                256
  Cur PV                1
  Act PV                1
  VG Size               186.25 GB
  PE Size               32.00 MB
  Total PE              5960
  Alloc PE / Size       5960 / 186.25 GB
  Free  PE / Size       0 / 0   
  VG UUID               BXOGJQ-3hhw-4TQC-1Z8W-pYL5-rLf3-NUXXkB
   
  Invalid LV in extent map (PV /dev/hda7, PE 1792, LV 4, LE 0)
  Couldn't fill logical volume maps.
  Invalid LV in extent map (PV /dev/hda7, PE 1792, LV 4, LE 0)
  Couldn't fill logical volume maps.
  Volume group "sys_vg" not found

Happily, the volumes in sys_vg stayed active for long enough for me
to be able to copy data off, but on reboot, there was no sign of the
LVM tools being able to read them (no logs of this, as I wasn't able
to bring up the system in multi-user mode).

I would have thought that the lvm tools should refuse to operate on
LVM1 volumes if doing so would corrupt them.

Further evidence of this on:
http://weblog.pell.portland.or.us/~orc/2008/02/20/000/index.html

Almost certainly not a Debian-specific bug, but this IMO, this is a severe
enough problem to warrant recording widely.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (900, 'stable'), (10, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-4-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages lvm-common depends on:
ii  libc6                  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  module-init-tools      3.3-pre4-2        tools for managing Linux kernel mo
ii  modutils               2.4.27.0-6        Linux module utilities

Versions of packages lvm-common recommends:
ii  logrotate                     3.7.1-3    Log rotation utility

-- no debconf information