[linux-lvm] Help! Problems finding VG after reboot.

[linux-lvm] Help! Problems finding VG after reboot.

[gobo]

Hi all.

I'm running beta3 on a 2.4.0 kernel. I recently had to reboot my computer 
due to an error with the network device. When the computer came back up I 
couldn't get to the LVM partition any more.

Running vgscan I got the following message:

# vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found inactive volume group "widow"
vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get 
data of volume group "widow" from physical volume(s)
vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" creating 
"/etc/lvmtab" and "/etc/lvmtab.d"

Running PVscan yielded:

# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- inactive PV "/dev/hda3"  is associated to an unknown VG (run 
vgscan)
pvscan -- inactive PV "/dev/hdb1"  is associated to an unknown VG (run 
vgscan)
pvscan -- inactive PV "/dev/hdc1"  is associated to an unknown VG (run 
vgscan)
pvscan -- inactive PV "/dev/hdd1"  is associated to an unknown VG (run 
vgscan)
pvscan -- inactive PV "/dev/hde1"  is associated to an unknown VG (run 
vgscan)
pvscan -- inactive PV "/dev/hdf1"  is associated to an unknown VG (run 
vgscan)
pvscan -- total: 6 [100.96 GB] / in use: 6 [100.96 GB] / in no VG: 0 [0]

After reading through the mailing list I got the impression that the 
thing to do to solve my problems would be to run vgcfgrestore on each 
partition. So I ran the following command on all 6 partitions:
# vgcfgrestore -n widow /dev/hdf1
vgcfgrestore -- VGDA for "widow" successfully restored to physical volume 
"/dev/hdf1"

Now when I run vgscan I get:
# vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- no volume groups found

and pvscan yields the exact same result as above.

If anyone have an idea on how I can get my filesystem back I'd very much 
appreciate it.

Frank Ronny Larsen
-- 
"I'll carry your books, I'll carry a tune, I'll carry on, carry over,
carry forward, Cary Grant, cash & carry, Carry Me Back To Old
Virginia, I'll even Hara Kari if you show me how, but I will *not*
carry a gun."                                      -- Hawkeye, M*A*S*H

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Rik van Riel]

On Tue, 6 Feb 2001 gobo@gimle.nu wrote:

> Running vgscan I got the following message:
> 
> # vgscan
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- found inactive volume group "widow"
> vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get 
> data of volume group "widow" from physical volume(s)
> vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" creating 
> "/etc/lvmtab" and "/etc/lvmtab.d"

I am running into the same bug, with the very latest LVM
utilities and kernel 2.4.1.

I have posted a bugreport in the LVM bugzilla, but I haven't
heard anything from the LVM developers. Lets just hope they're
not ignoring us...

> If anyone have an idea on how I can get my filesystem back I'd
> very much appreciate it.

LVM 0.8final with the lvm-iop6 tools (as shipped by Conectiva)
seem to be able to use this volume group just fine. The utilities
still complain and I cannot change any configuration things, but
at least I can access my data...

For now, there's nothing we can do until the LVM people acknowledge
and fix our bug. ;(

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] Help! Problems finding VG after reboot.

[AJ Lewis]

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

On Tue, Feb 06, 2001 at 04:58:22PM -0200, Rik van Riel wrote:
> On Tue, 6 Feb 2001 gobo@gimle.nu wrote:
> 
> > Running vgscan I got the following message:
> > 
> > # vgscan
> > vgscan -- reading all physical volumes (this may take a while...)
> > vgscan -- found inactive volume group "widow"
> > vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get 
> > data of volume group "widow" from physical volume(s)
> > vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" creating 
> > "/etc/lvmtab" and "/etc/lvmtab.d"
> 
> I am running into the same bug, with the very latest LVM
> utilities and kernel 2.4.1.
> 
> I have posted a bugreport in the LVM bugzilla, but I haven't
> heard anything from the LVM developers. Lets just hope they're
> not ignoring us...

The problem with your bug report on Bugzilla is that it is confusing.  You
added to a bug that complained about vgscan seg-faulting.  That bug is
obviously fixed.  The problem now is that vgscan no longer finds proper data
in the volume group.  This should be posted as a separate bug report, not
tacked onto the end of the old one.  

BTW, just because you haven't gotten an immediate reply does not mean the
problem is not being worked on.  We are a distributed development team,
with varying schedules.  Please give us a little credit that we are actually
reading the MLs and working on these problems instead of impatiently
complaining that nobody on the LVM team is doing anything all the time.  It
is rather tiring to see yet another post from you complaining that we don't do
anything.

-- 
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----------------------------------------
A bad random number generator: 1, 1, 1, 1, 1, 4.33e+67, 1, 1, 1...
-----End Obligatory Humorous Quote------------------------------------------

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

Re: [linux-lvm] Help! Problems finding VG after reboot.

[AJ Lewis]

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

On Tue, Feb 06, 2001 at 01:22:40PM -0600, AJ Lewis wrote:
> On Tue, Feb 06, 2001 at 04:58:22PM -0200, Rik van Riel wrote:
> > On Tue, 6 Feb 2001 gobo@gimle.nu wrote:
> > 
> > > Running vgscan I got the following message:
> > > 
> > > # vgscan
> > > vgscan -- reading all physical volumes (this may take a while...)
> > > vgscan -- found inactive volume group "widow"
> > > vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get 
> > > data of volume group "widow" from physical volume(s)
> > > vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" creating 
> > > "/etc/lvmtab" and "/etc/lvmtab.d"
> > 
> > I am running into the same bug, with the very latest LVM
> > utilities and kernel 2.4.1.
> > 
> > I have posted a bugreport in the LVM bugzilla, but I haven't
> > heard anything from the LVM developers. Lets just hope they're
> > not ignoring us...
> 
> The problem with your bug report on Bugzilla is that it is confusing.  You
> added to a bug that complained about vgscan seg-faulting.  That bug is
> obviously fixed.  The problem now is that vgscan no longer finds proper data
> in the volume group.  This should be posted as a separate bug report, not
> tacked onto the end of the old one.  

This is now bug #193 (http://bugzilla.sistina.com/show_bug.cgi?id=193)


-- 
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----------------------------------------
FATAL ERROR! SYSTEM HALTED! - Press any key to do nothing...
-----End Obligatory Humorous Quote------------------------------------------

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

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Rik van Riel]

On Tue, 6 Feb 2001, AJ Lewis wrote:

> The problem with your bug report on Bugzilla is that it is
> confusing.  You added to a bug that complained about vgscan
> seg-faulting.  That bug is obviously fixed. 

It still segfaults ... ;)

> The problem now is that vgscan no longer finds proper data in
> the volume group.  This should be posted as a separate bug
> report, not tacked onto the end of the old one.

It's still vg_read_with_pv_and_le() that's spitting out
errors and causing vgscan to segfault. The error I am
seeing here hasn't changed in the last month...

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] Help! Problems finding VG after reboot.

[AJ Lewis]

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

On Tue, Feb 06, 2001 at 06:09:15PM -0200, Rik van Riel wrote:
> On Tue, 6 Feb 2001, AJ Lewis wrote:
> 
> > The problem with your bug report on Bugzilla is that it is
> > confusing.  You added to a bug that complained about vgscan
> > seg-faulting.  That bug is obviously fixed. 
> 
> It still segfaults ... ;)

Oh, sorry.  That was not obvious from your vgscan -d dump.  Frank didn't say
anything about a segfault either.

> > The problem now is that vgscan no longer finds proper data in
> > the volume group.  This should be posted as a separate bug
> > report, not tacked onto the end of the old one.
> 
> It's still vg_read_with_pv_and_le() that's spitting out
> errors and causing vgscan to segfault. The error I am
> seeing here hasn't changed in the last month...

Hmm...This appears to be different from the bug posted with the subject
"0.9.1 vgscan doesn't detect upgraded vg's" today.  Can you confirm this?

Have you been able to get to your data since you first posted the bug
report?  What steps did you take to get to this point?  What I'm wondering
is this:  did your attempt to use the LVM tools with the broken kernel patch
in 2.4.0 mess up the on-disk format, or is this a continued problem that can
be reproduced with new VGs created with 0.9.1_beta3 or converted with the
latest tools from 0.8final or 0.8.1?

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----------------------------------------
A morning without coffee is like something without something else.
-----End Obligatory Humorous Quote------------------------------------------

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

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Rik van Riel]

On Tue, 6 Feb 2001, AJ Lewis wrote:

> > It's still vg_read_with_pv_and_le() that's spitting out
> > errors and causing vgscan to segfault. The error I am
> > seeing here hasn't changed in the last month...
> 
> Hmm...This appears to be different from the bug posted with the
> subject "0.9.1 vgscan doesn't detect upgraded vg's" today.  Can
> you confirm this?

I'm not sure if it's related or not ...

> Have you been able to get to your data since you first posted
> the bug report?  What steps did you take to get to this point?

I am able to use my data with 0.8final on Conectiva's kernel RPM.

Basically, I have 3 PVs in my VG:

PV1: /dev/hdd1   (full)
PV2: /dev/hdb1   (almost full)
PV3: /dev/hda5   (still empty)

Whenever I run vgscan, it will encounter the (empty) hda5
first and somehow gets confused.

Removing /dev/hda5 from my VG meant I could use 2.4.0 and
normally access my data. Doing a pvextend /dev/hda5 gave
a kernel oops. This removing had to be done with 0.8final
since 0.9+tools were confused.

In 2.4.1, I did a pvextend vg0 /dev/hda5 and everything
seemed to work fine. Didn't get around to grow a filesystem
into the last PV.

When I came back after a power failure, I found my system
in a rather bad state. Now I am unable to remove /dev/hda5
from me VG or grow a LV into that VG ... all tools seem
confused. Luckily I can still access the data using 0.8.

The fact that 0.8 and 0.9 fail in different ways, however,
seems to suggest that there's nothing but simple implementation
bugs keeping me from using my system with 2.4 again and testing
if my latest VM changes really help ;)

> What I'm wondering is this:  did your attempt to use the LVM
> tools with the broken kernel patch in 2.4.0 mess up the on-disk
> format,

I don't think this is the case since the 0.8final tools
(and kernel driver) didn't complain after my 2.4.0 tests.
However, after my 2.4.1 tests I'm no longer completely sure.

> or is this a continued problem that can be reproduced
> with new VGs created with 0.9.1_beta3 or converted with the
> latest tools from 0.8final or 0.8.1?

I haven't created any VGs with the new tools, this thing
comes straight from 0.8final (+fixed tools, close to 0.8.1).

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] Help! Problems finding VG after reboot.

[gobo]

> On Tue, Feb 06, 2001 at 06:09:15PM -0200, Rik van Riel wrote:
> > On Tue, 6 Feb 2001, AJ Lewis wrote:
> > > The problem with your bug report on Bugzilla is that it is
> > > confusing.  You added to a bug that complained about vgscan
> > > seg-faulting.  That bug is obviously fixed.=20
> > It still segfaults ... ;)
> 
> Oh, sorry.  That was not obvious from your vgscan -d dump.  Frank didn't say
> anything about a segfault either.

No, I don't get segfaults. Although it is vg_read_with_pv_and_lv() that 
fails. After I tried using vgcfgrestore it doesn't find any VGs at all.

> > It's still vg_read_with_pv_and_le() that's spitting out
> > errors and causing vgscan to segfault. The error I am
> > seeing here hasn't changed in the last month...
> 
> Hmm...This appears to be different from the bug posted with the subject
> "0.9.1 vgscan doesn't detect upgraded vg's" today.  Can you confirm this?

Well. In my case the VG in question was extended a little while back. 
Possibly between the last reboot and this one. But it was originally 
built with the 0.9.0 tools and stock 2.4.0 kernel.

BTW: Should the LVM be switched of somehow before reboot of the computer?

FrankRL
-- 
                                  I don't suffer from insanity.
                                    I enjoy every minute of it.
gobo@gimle.nu

Re: [linux-lvm] Help! Problems finding VG after reboot.

[gobo]

> Hmm...This appears to be different from the bug posted with the subject
> "0.9.1 vgscan doesn't detect upgraded vg's" today.  Can you confirm this?

Having read through the thread you mention it seems that my problem is a 
bit different, although it might have the same source.

I tried viewing the output of pvdata as shown in that thread, and I think 
that might be the source of my problems. At least if all the UUIDs are 
supposed to be equal.

I have attached the results from that to this mail along with the results form running vgcfgrestore -ll. Please note that the pvdata outputs are taken after I had tried running vgcfgrestore on all the partitions.

I hope someone has a way/hack to get this VG back online. I would really appreciate getting my files back.

BTW: You're doing a great job people. Now if we can just stamp out the bugs this is going to be one of the most useful features in the kernel.

FrankRL

Re: [linux-lvm] Help! Problems finding VG after reboot.

[gobo]

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

gobo@gimle.nu said:
> I have attached the results from that to this mail along with the
> results form running vgcfgrestore -ll. Please note that the pvdata
> outputs are taken after I had tried running vgcfgrestore on all the
> partitions. 

At least I would have if I remembered...
Here goes.

[-- Attachment #2: cfg.txt --]
[-- Type: text/plain , Size: 5898 bytes --]

> vgcfgrestore -n widow -ll

--- Volume group ---
VG Name               widow
VG Access             read/write
VG Status             NOT available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           1023.97 GB
Max PV                256
Cur PV                6
Act PV                6
VG Size               100.92 GB
PE Size               16 MB
Total PE              6459
Alloc PE / Size       6400 / 100 GB
Free  PE / Size       59 / 944 MB
VG UUID               FI7LcR-QWYd-BXPd-1db8-r3HA-UbNg-KbeuEV

--- Logical volume ---
LV Name                /dev/widow/Store
VG Name                widow
LV Write Access        read/write
LV Status              NOT available
LV #                   1
# open                 0
LV Size                100 GB
Current LE             6400
Allocated LE           6400
Allocation             next free
Read ahead sectors     120
Block device           58:0


--- Physical volume ---
PV Name               /dev/hde1
VG Name               widow
PV Size               19.11 GB / NOT usable 3.34 MB [LVM: 125 KB]
PV#                   1
PV Status             NOT available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       16384
Total PE              1223
Free PE               0
Allocated PE          1223
PV UUID               fFAg5P-kKUz-lBqn-Vryd-GS21-hM8R-5pJaMZ

--- Physical volume ---
PV Name               /dev/hdf1
VG Name               widow
PV Size               19.01 GB / NOT usable 13.37 MB [LVM: 125 KB]
PV#                   2
PV Status             available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       16384
Total PE              1216
Free PE               0
Allocated PE          1216
PV UUID               GwPjBK-QDs1-jFo8-uPSF-MaMO-rE70-AmqW8F

--- Physical volume ---
PV Name               /dev/hdd1
VG Name               widow
PV Size               15.71 GB / NOT usable 4.66 MB [LVM: 124 KB]
PV#                   3
PV Status             NOT available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       16384
Total PE              1005
Free PE               0
Allocated PE          1005
PV UUID               qGIXjD-BEvX-0JRu-60dE-bbyg-BVyd-ERCwPN

--- Physical volume ---
PV Name               /dev/hdc1
VG Name               widow
PV Size               15.71 GB / NOT usable 4.66 MB [LVM: 124 KB]
PV#                   4
PV Status             NOT available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       16384
Total PE              1005
Free PE               0
Allocated PE          1005
PV UUID               2mdFvi-PRwZ-bELK-hWw4-lQYU-SCTR-2l3gRH

--- Physical volume ---
PV Name               /dev/hdb1
VG Name               widow
PV Size               15.71 GB / NOT usable 4.66 MB [LVM: 124 KB]
PV#                   5
PV Status             NOT available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       16384
Total PE              1005
Free PE               0
Allocated PE          1005
PV UUID               QLlu9k-KJk7-4lv0-QKKf-PUMO-Lctn-Vblo2z

--- Physical volume ---
PV Name               /dev/hda3
VG Name               widow
PV Size               15.71 GB / NOT usable 4.69 MB [LVM: 124 KB]
PV#                   6
PV Status             available
Allocatable           yes
Cur LV                1
PE Size (KByte)       16384
Total PE              1005
Free PE               59
Allocated PE          946
PV UUID               g7Z7su-WzkZ-LIaA-w1HY-l7au-HMDH-XHuCRo


> pvdata -U /dev/hda3

--- List of physical volume UUIDs ---

000: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
001: qGIXjDBEvX0JRu60dEbbygBVydERCwPN
002: 2mdFviPRwZbELKhWw4lQYUSCTR2l3gRH
003: QLlu9kKJk74lv0QKKfPUMOLctnVblo2z
004: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
005: --- EMPTY ---

> pvdata -U /dev/hdb1

--- List of physical volume UUIDs ---

000: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
001: qGIXjDBEvX0JRu60dEbbygBVydERCwPN
002: 2mdFviPRwZbELKhWw4lQYUSCTR2l3gRH
003: QLlu9kKJk74lv0QKKfPUMOLctnVblo2z
004: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
005: --- EMPTY ---

> pvdata -U /dev/hdc1

--- List of physical volume UUIDs ---

000: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
001: qGIXjDBEvX0JRu60dEbbygBVydERCwPN
002: 2mdFviPRwZbELKhWw4lQYUSCTR2l3gRH
003: QLlu9kKJk74lv0QKKfPUMOLctnVblo2z
004: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
005: --- EMPTY ---

> pvdata -U /dev/hdd1

--- List of physical volume UUIDs ---

000: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
001: qGIXjDBEvX0JRu60dEbbygBVydERCwPN
002: 2mdFviPRwZbELKhWw4lQYUSCTR2l3gRH
003: QLlu9kKJk74lv0QKKfPUMOLctnVblo2z
004: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
005: --- EMPTY ---

> pvdata -U /dev/hde1

--- List of physical volume UUIDs ---

000: fFAg5PkKUzlBqnVrydGS21hM8R5pJaMZ
001: qGIXjDBEvX0JRu60dEbbygBVydERCwPN
002: 2mdFviPRwZbELKhWw4lQYUSCTR2l3gRH
003: QLlu9kKJk74lv0QKKfPUMOLctnVblo2z
004: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
005: --- EMPTY ---

> pvdata -U /dev/hdf1

--- List of physical volume UUIDs ---

000: GwPjBKQDs1jFo8uPSFMaMOrE70AmqW8F
001: qGIXjDBEvX0JRu60dEbbygBVydERCwPN
002: 2mdFviPRwZbELKhWw4lQYUSCTR2l3gRH
003: QLlu9kKJk74lv0QKKfPUMOLctnVblo2z
004: g7Z7suWzkZLIaAw1HYl7auHMDHXHuCRo
005: --- EMPTY ---

> pvdata -V /dev/hdf1

--- Volume group ---
VG Name               
VG Access             read/write
VG Status             NOT available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           1023.97 GB
Max PV                256
Cur PV                6
Act PV                6
VG Size               100.92 GB
PE Size               16 MB
Total PE              6459
Alloc PE / Size       6400 / 100 GB
Free  PE / Size       59 / 944 MB
VG UUID               FI7LcR-QWYd-BXPd-1db8-r3HA-UbNg-KbeuEV

> vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- no volume groups found

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Andreas Dilger]

Gobo writes:
> I tried viewing the output of pvdata as shown in that thread, and I think 
> that might be the source of my problems. At least if all the UUIDs are 
> supposed to be equal.
> 
> I have attached the results from that to this mail along with the results
> form running vgcfgrestore -ll. Please note that the pvdata outputs are
> taken after I had tried running vgcfgrestore on all the partitions.
> 
> I hope someone has a way/hack to get this VG back online. I would really
> appreciate getting my files back.

There are two ways to fix this:

1) comment out the UUID checking in pv_read_all_pv_of_vg(), recompile.
2) apply the UUID patch I posted to the list a few hours ago, recompile
   and re-run vgcfgrestore.  This patch will force creation of new UUIDs
   for all PVs which are missing them, and it will do it properly so
   that they are stored on all disks.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Michael E Brown]

On Tue, 6 Feb 2001, AJ Lewis wrote:

> BTW, just because you haven't gotten an immediate reply does not mean the
> problem is not being worked on.  We are a distributed development team,
> with varying schedules.  Please give us a little credit that we are actually
> reading the MLs and working on these problems instead of impatiently
> complaining that nobody on the LVM team is doing anything all the time.  It
> is rather tiring to see yet another post from you complaining that we don't do
> anything.

I'll second this... The ratio of '@sistina.com' addresses to other
addresses is very high, compared to other vendor mailing lists I've seen.
Also, I've not seen many bugs not get looked at, except for the obvious
cases where the user didn't provide enough info to properly diagnose them.
I, for one, think these guys are doing a great job for what they are
doing.

--
Michael Brown
Linux Systems Group
Dell Computer Corp

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Richard Smith]

--snip--
I agree as well.

The .9 versions are still marked as beta.
I have been banging it around abit, but I would
not trust important data to it yet, without a backup.

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Gregory McLean]

On Tue, 6 Feb 2001, Richard Smith wrote:

> --snip--
> I agree as well.
>
> The .9 versions are still marked as beta.
> I have been banging it around abit, but I would
> not trust important data to it yet, without a backup.

I would have to agree also, vgscan no longer works here either, I've
edited around in the startup files to _not_ call vgscan at all and things
are working for now. Though if I need to add a drive to the system I'm
screwed.

Re: [linux-lvm] Help! Problems finding VG after reboot.

[Andreas Dilger]

Gregory McLean writes:
> I've edited around in the startup files to _not_ call vgscan at all
> and things are working for now. Though if I need to add a drive to
> the system I'm screwed.

I disagree.  I never have vgscan in my system startup, and have never
had problems.  The only time I run vgscan is by accident, or on my
rescue partition (where the VGDA info can get out of date).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert