[linux-lvm] [BUG] Spaces in LVM1 LV names => *deep trouble* when converting to LVM2

[linux-lvm] [BUG] Spaces in LVM1 LV names => *deep trouble* when converting to LVM2

[Dominique Quatravaux]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, I encountered a very serious bug with LVM today. I'm using
lvm2-2.01.04-5 from Debian stable, kernel 2.6.17-rc3

# lvm version
  LVM version:     2.01.04 (2005-02-09)
  Library version: 1.01.00-ioctl (2005-01-17)
  Driver version:  4.6.0

What I did:

    * created a LV in an LVM1 VG using EVMS (yeah, I know) with a
      space in the name (yeah, yeah, I know, I know :-));
    * converted the VG to LVM2 using vgconvert;
    * as a result the space in the LVM1 metadata was converted over
      into a space in LVM2 textual metadata, which causes a nice
      "Parse error line 123" for every subsequent LVM command on that
      VG, including "vgcfgrestore"...

Of course I did that on the root VG of my work laptop (Backups? What
backups?) and ended up in the aforementioned pickle. I tried some dd
stunts to overwrite the space with a dash, having discovered the
correct offset and block size with strace() (which for the record were
respectively one block and 2560 bytes, YMMV) - But bummer, some
wiseguy put a CRC32 checksum in there! :-) I had to recompile a custom
version of lvm that passes NULL as the checksum_fn parameter to
text_vg_import_fd (again for the record, that's a trivial one-line
patch in function _vg_read_raw_area, in format-text.c around line 286).

The situation definitely needs some fixing. My humble suggestions:

    * vgconvert should surface-test the LVM1 metadata as strictly as
      the command-line "lvcreate" tool does on its arguments;
    * there should be a mechanism for dealing with corrupt LVM
      metadata, at the minimum a global command-line switch to
      temporarily disable checksum verifications.

Now investigating backup software *real seriously* :-) Thanks for your
work on the Linux LVM suite,

- --
Dominique QUATRAVAUX                           Ing�nieur senior
01 44 42 00 08                                 IDEALX

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEYkxmMJAKAU3mjcsRApAFAJ4tCEJ0pK1bIBWruaq5VDu2izf75gCeKQCC
zzsNGFC6lPaRBvpRy2am/TM=
=ad0C
-----END PGP SIGNATURE-----

Re: [linux-lvm] [BUG] Spaces in LVM1 LV names => *deep trouble* when converting to LVM2

[Alasdair G Kergon]

On Wed, May 10, 2006 at 10:26:14PM +0200, Dominique Quatravaux wrote:
> Hi, I encountered a very serious bug with LVM today. I'm using
> lvm2-2.01.04-5 from Debian stable, kernel 2.6.17-rc3
> # lvm version
>   LVM version:     2.01.04 (2005-02-09)
>   Library version: 1.01.00-ioctl (2005-01-17)
>   Driver version:  4.6.0
> What I did:
>     * created a LV in an LVM1 VG using EVMS (yeah, I know) with a
>       space in the name (yeah, yeah, I know, I know :-));

LVs are not permitted to have spaces in their names.
EVMS should have prevented you from doing that!

>     * converted the VG to LVM2 using vgconvert;
>     * as a result the space in the LVM1 metadata was converted over
>       into a space in LVM2 textual metadata, which causes a nice
>       "Parse error line 123" for every subsequent LVM command on that
>       VG, including "vgcfgrestore"...
> 
> Of course I did that on the root VG of my work laptop (Backups? What
> backups?) and ended up in the aforementioned pickle. I tried some dd
> stunts to overwrite the space with a dash, having discovered the
> correct offset and block size with strace() (which for the record were
> respectively one block and 2560 bytes, YMMV) - But bummer, some
> wiseguy put a CRC32 checksum in there! :-) I had to recompile a custom
> version of lvm that passes NULL as the checksum_fn parameter to
> text_vg_import_fd (again for the record, that's a trivial one-line
> patch in function _vg_read_raw_area, in format-text.c around line 286).
> 
> The situation definitely needs some fixing. My humble suggestions:
> 
>     * vgconvert should surface-test the LVM1 metadata as strictly as
>       the command-line "lvcreate" tool does on its arguments;

Some metadata sanity checks are always performed before writing out
metadata.  They're designed to trap internal errors to stop
the programs writing out invalid metadata.  I'll see about enhancing
them to catch this sort of problem.

>     * there should be a mechanism for dealing with corrupt LVM
>       metadata, at the minimum a global command-line switch to
>       temporarily disable checksum verifications.

Nope.
 
Alasdair
-- 
agk@redhat.com

Re: [linux-lvm] [BUG] Spaces in LVM1 LV names => *deep trouble* when converting to LVM2

[Alasdair G Kergon]

On Wed, May 10, 2006 at 09:36:26PM +0100, Alasdair G Kergon wrote:
> On Wed, May 10, 2006 at 10:26:14PM +0200, Dominique Quatravaux wrote:
> >     * there should be a mechanism for dealing with corrupt LVM
> >       metadata, at the minimum a global command-line switch to
> >       temporarily disable checksum verifications.
> 
> Nope.
  
I should add that what you should do is extract the metadata you've
retrieved off disk directly into a file, fix it in the file
(differences in whitespace & comments don't matter) then use 
vgcfgrestore -f.

Alasdair
-- 
agk@redhat.com

Re: [Evms-devel] Re: [linux-lvm] [BUG] Spaces in LVM1 LV names => *deep trouble* when converting to LVM2

[Kevin Corry]

On Wed May 10 2006 3:36 pm, Alasdair G Kergon wrote:
> On Wed, May 10, 2006 at 10:26:14PM +0200, Dominique Quatravaux wrote:
> > Hi, I encountered a very serious bug with LVM today. I'm using
> > lvm2-2.01.04-5 from Debian stable, kernel 2.6.17-rc3
> > # lvm version
> >   LVM version:     2.01.04 (2005-02-09)
> >   Library version: 1.01.00-ioctl (2005-01-17)
> >   Driver version:  4.6.0
> > What I did:
> >     * created a LV in an LVM1 VG using EVMS (yeah, I know) with a
> >       space in the name (yeah, yeah, I know, I know :-));
>
> LVs are not permitted to have spaces in their names.
> EVMS should have prevented you from doing that!

Hmm...looks like the lvm2 format plugin in EVMS does check for spaces when 
creating a new VG or LV, but the lvm1 format plugin does not. I've added a 
patch to fix the lvm1 plugin. Sorry for the trouble. :(  I guess this case is 
sufficiently unusual that no one has hit before, or at least not mentioned it 
to me before.

-- 
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
http://evms.sourceforge.net/

Re: [linux-lvm] [BUG] Spaces in LVM1 LV names => *deep trouble* when converting to LVM2

[Dominique Quatravaux]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alasdair G Kergon wrote:

>
> I should add that what you should do is extract the metadata you've
> retrieved off disk directly into a file, fix it in the file
> (differences in whitespace & comments don't matter) then use
> vgcfgrestore -f.

I tried that and it works - strange, I tried vgcfgrestore yesterday to
no avail... But then I was using Ubuntu 5.10's lvm2 package as a
rescue so apparently it's a different (and solved) issue. Thanks!

Knowing this, and still for the record: after any LVM operation it
seems wise to try a vgchange -a y *before* rebooting to see if
everything went well. Reverting a pickled LVM situation is much easier
with the original toolset handy (same LVM binary and metadata backups
in /etc/lvm/) than using a rescue CD!


I wrote, and you replied:

>> * there should be a mechanism for dealing with corrupt LVM
>> metadata, at the minimum a global command-line switch to
>> temporarily disable checksum verifications.
>
> Nope.
>

I seem to have pushed your button, apologies for doing so. I was
trying to be humorous, not disparaging: *of course* I concur that
checksums are a good idea! I guess it means that humor is too slippery
for us non-native speakers, oh well...

- --
Dominique QUATRAVAUX                           Ing�nieur senior
01 44 42 00 08                                 IDEALX

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEYu3XMJAKAU3mjcsRAugqAKC2KK88j/+w30xd6pxcn/5Juu7tuACdExXi
R2b4HLcvmPmWHl+uxhbvGi0=
=tWX0
-----END PGP SIGNATURE-----