[linux-lvm] Re: [lvm-commit] cvs commit: LVM/tools/lib pv_read_all_pv_of_vg.c

[linux-lvm] Re: [lvm-commit] cvs commit: LVM/tools/lib pv_read_all_pv_of_vg.c

[Rik van Riel]

On Wed, 7 Feb 2001, Heinz Mauelshagen wrote:

>   Modified files:        (Branch: LVM_0-9-patches)
>     tools/lib            pv_read_all_pv_of_vg.c 
>   Log:
>   fixed multiple access path avoidance problem
>   leading to removed but valid PV structure;
>   this could probably be the reason for lost PVs we faced in the past

I've gathered a bit more debugging output to see why even
this fix failed to make vgscan run.

It turns out the LVM utilities messed up some of the info
in the PV headers so badly that there's no way to reasonably
expect the LVM utilities to pick up their mess ...

I have attached the output from pvdata -a on the PVs to:
	http://bugzilla.sistina.com/show_bug.cgi?id=193

Would it be an idea to have some debugging tool around which
allows us to fix (simple) things like this ourselves ?

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [linux-lvm] Re: [lvm-commit] cvs commit: LVM/tools/lib pv_read_all_pv_of_vg.c

[AJ Lewis]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Wed, Feb 07, 2001 at 06:29:24PM -0200, Rik van Riel wrote:
> On Wed, 7 Feb 2001, Heinz Mauelshagen wrote:
> 
> >   Modified files:        (Branch: LVM_0-9-patches)
> >     tools/lib            pv_read_all_pv_of_vg.c 
> >   Log:
> >   fixed multiple access path avoidance problem
> >   leading to removed but valid PV structure;
> >   this could probably be the reason for lost PVs we faced in the past
> 
> I've gathered a bit more debugging output to see why even
> this fix failed to make vgscan run.
> 
> It turns out the LVM utilities messed up some of the info
> in the PV headers so badly that there's no way to reasonably
> expect the LVM utilities to pick up their mess ...
> 
> I have attached the output from pvdata -a on the PVs to:
> 	http://bugzilla.sistina.com/show_bug.cgi?id=193
> 
> Would it be an idea to have some debugging tool around which
> allows us to fix (simple) things like this ourselves ?

It looks like the following *should* fix things for you (this from Patrick):

 o Grab the latest CVS code for LVM.
 o Create a very small LV (or extend an existing one) to force a meta-data
   update.
 o The UUIDs should be cleaned up

If this is not possible with your setup, or does not work for you, let me
know and we'll see what else we can do to fix the problem.

Regards,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-----Begin Obligatory Humorous Quote----------------------------------------
Proofread carefully to see if you any words out.
-----End Obligatory Humorous Quote------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Re: [lvm-commit] cvs commit: LVM/tools/lib pv_read_all_pv_of_vg.c

[Rik van Riel]

On Wed, 7 Feb 2001, AJ Lewis wrote:
> On Wed, Feb 07, 2001 at 06:29:24PM -0200, Rik van Riel wrote:

> > Would it be an idea to have some debugging tool around which
> > allows us to fix (simple) things like this ourselves ?
> 
> It looks like the following *should* fix things for you (this from Patrick):
> 
>  o Grab the latest CVS code for LVM.
>  o Create a very small LV (or extend an existing one) to force a meta-data
>    update.
>  o The UUIDs should be cleaned up
> 
> If this is not possible with your setup, or does not work for
> you, let me know and we'll see what else we can do to fix the
> problem.

# lvcreate -h
lvcreate -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

(yes, every utility except for vgscan and pvdata
seem to spit out this complaint ...)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [linux-lvm] Re: [lvm-commit] cvs commit: LVM/tools/lib pv_read_all_pv_of_vg.c

[Rik van Riel]

On Wed, 7 Feb 2001, Rik van Riel wrote:
> On Wed, 7 Feb 2001, AJ Lewis wrote:

> > It looks like the following *should* fix things for you (this from Patrick):
> 
> # lvcreate -h
> lvcreate -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

Oooops, this was in a running system with lvm 0.8,
in the not-runnable system with 0.9.x (latest from
CVS) I get the following:

# lvcreate -h
lvcreate -- ERROR: "/etc/lvmtab" doesn't exist; please run vgscan

(and, of course, vgscan doesn't work because the metadata
is inconsistent -- catch22)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/