Linux

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • Spaces in LVM1 LV names => *deep trouble* whenconverting to LVM2

    4 answers - 2244 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    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"
    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 I senior
    01 44 42 00 08 IDEALX
    PGP SIGNATURE
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
    zzsNGFC6lPaRBvpRy2am/TM=
    =ad0C
    PGP SIGNATURE
    linux-lvm mailing list
    linux-lvm (AT) redhat (DOT) com
    read the LVM HW-T at http://tldp.org/HWT/LVM-HWT/
  • No.1 | | 959 bytes | |

    Wed May 10 2006 3:36 pm, Alasdair G Kergon wrote:
    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!

    Hmmlooks 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.
  • No.2 | | 2154 bytes | |

    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"

    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
  • No.3 | | 564 bytes | |

    Wed, May 10, 2006 at 09:36:26PM +0100, Alasdair G Kergon wrote:
    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
  • No.4 | | 1749 bytes | |

    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 I senior
    01 44 42 00 08 IDEALX

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

    R2b4HLcvmPmWHl+uxhbvGi0=
    =tWX0
    PGP SIGNATURE

    linux-lvm mailing list
    linux-lvm (AT) redhat (DOT) com

    read the LVM HW-T at http://tldp.org/HWT/LVM-HWT/

Re: Spaces in LVM1 LV names => *deep trouble* whenconverting to LVM2


max 4000 letters.
Your nickname that display:
In order to stop the spam: 3 + 2 =
QUESTION ON "Linux"

EMSDN.COM