How to fix inconsistent LV structs?

linux-lvm Raffael Herzog 3 participants 8 messages Oct 5, 2002 – Oct 9, 2002

Share & tools

Raffael Herzog

author

2002-10-05 17:48 UTC #0 lore raw

Hi,

After a normal reboot I lost my volumes. I don't know, what exatly happended, but it looks like there was some problem with AVFS that caused umount not to work properly. I turned AVFS off now, but this doesn't get me my LVs back.

pvdata shows me, that the logical volume structs 125 through 139 are inconsistent (there are no LVs there), at some later point, it segfaults. Debug output showed me, that there's some garbage in these logical volume structs.

My basic idea is to just clear these structs and then use vgcfgrestore and/or the other recovery tools (which current- ly all fail with "pv_read(): read") to restore my LVs.

But how do I clear these structs?

TIA,

Raffi

Heinz J . Mauelshagen

2002-10-07 03:53 UTC #1 lore raw

Quoted 11 lines · Raffael Herzog

Hi,
After a normal reboot I lost my volumes. I don't know, what exatly happended, but it looks like there was some problem with AVFS that caused umount not to work properly. I turned AVFS off now, but this doesn't get me my LVs back.
pvdata shows me, that the logical volume structs 125 through 139 are inconsistent (there are no LVs there), at some later point, it segfaults. Debug output showed me, that there's some garbage in these logical volume structs.

Hmmm...
Sounds like a nasty overwrite but it is hard to tell because you can't remmeber the exact details :(

Quoted 6 lines

My basic idea is to just clear these structs and then use vgcfgrestore and/or the other recovery tools (which current- ly all fail with "pv_read(): read") to restore my LVs.
But how do I clear these structs?

Presuming that the metadata backups are intact, you need to "pvcreate -ff" the physical volumes and run vgcfgrestore on each of them. "vgscan ; vgchange -ay" should get you back to business afterwards.

Quoted 14 lines

TIA,
Raffi
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Signature · 15 lines

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Raffael Herzog

author

2002-10-07 04:29 UTC #2 lore raw

Hi Heinz,

Quoted 3 lines · Heinz J . Mauelshagen

Hmmm...
Sounds like a nasty overwrite but it is hard to tell because you can't remmeber the exact details :(

Well, I can, the syslog is one of the only things that still exist, besides the backup... :-) These are the last few messages of the catastrophic reboot:

,----[ /var/log/syslog ]

| Oct  5 21:08:33 rumba kernel: Coda: Bye bye.
| Oct  5 21:08:33 rumba kernel: redir cleanup
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  12 [e0a01674] with [c012e408]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 106 [e0a017a0] with [c0134ad0]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 107 [e0a0184c] with [c0134bb0]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  33 [e0a018fc] with [c012e2dc]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.   5 [e0a019c0] with [c012ecb4]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  85 [e0a01a9c] with [c0134ce0]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 183 [e0a01bd0] with [c013ef44]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 195 [e0a01d7c] with [c0134ebc]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 196 [e0a01e30] with [c0134f30]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  11 [e0a01f4c] with [c0105a30]
| Oct  5 21:08:33 rumba kernel: Unable to handle kernel paging request at virtual address e0a019fb
| Oct  5 21:08:33 rumba kernel:  printing eip:
| Oct  5 21:08:33 rumba kernel: e0a019fb
| Oct  5 21:08:33 rumba kernel: *pde = 01870067
| Oct  5 21:08:33 rumba kernel: *pte = 00000000
| Oct  5 21:08:33 rumba kernel: Oops: 0000
| Oct  5 21:08:33 rumba kernel: CPU:    0
| Oct  5 21:08:33 rumba kernel: EIP:    0010:[<e0a019fb>]    Tainted: P 
| Oct  5 21:08:33 rumba kernel: EFLAGS: 00010286
| Oct  5 21:08:33 rumba kernel: eax: 00000005   ebx: 08094482   ecx: d27ea3e0   edx: c1807ea0
| Oct  5 21:08:33 rumba kernel: esi: 00000241   edi: 08094482   ebp: dcda5fbc   esp: dcda5f94
| Oct  5 21:08:33 rumba kernel: ds: 0018   es: 0018   ss: 0018
| Oct  5 21:08:33 rumba kernel: Process avfscoda (pid: 354, stackpage=dcda5000)
| Oct  5 21:08:33 rumba kernel: Stack: 08094482 00000241 000001b6 dd27e360 dcda4000 00000241 08094482 00000001 
| Oct  5 21:08:33 rumba kernel:        c0141df8 c0106e0c bffff6f8 c0106d1b 08094482 00000241 000001b6 00000241 
| Oct  5 21:08:33 rumba kernel:        08094482 bffff6f8 00000005 0000002b 0000002b 00000005 4017b2e4 00000023 
| Oct  5 21:08:33 rumba kernel: Call Trace: [sys_oldumount+12/16] [error_code+52/60] [system_call+51/56] 
| Oct  5 21:08:33 rumba kernel: 
| Oct  5 21:08:33 rumba kernel: Code:  Bad EIP value.
| Oct  5 21:08:33 rumba kernel:  <6>i8k: module unloaded
| Oct  5 21:08:35 rumba nmbd[7091]: [2002/10/05 21:08:35, 0] nmbd/nmbd.c:sig_term(63) 
| Oct  5 21:08:35 rumba nmbd[7091]:   Got SIGTERM: going down... 
| Oct  5 21:08:35 rumba xfs[593]: terminating 
| Oct  5 21:08:35 rumba xfs[594]: terminating 
| Oct  5 21:08:35 rumba ntpd[604]: ntpd exiting on signal 15
| Oct  5 21:08:36 rumba usbmgr[12064]: umount /proc/bus/usb
| Oct  5 21:08:36 rumba rpc.statd[265]: Caught signal 15, un-registering and exiting.
| Oct  5 21:08:36 rumba kernel: Kernel logging (proc) stopped.
| Oct  5 21:08:36 rumba kernel: Kernel log daemon terminating.
| Oct  5 21:08:36 rumba exiting on signal 15

`----

For a very short time (that laptop is *fast* :-) I've seen a message about a failed umount, then it went down and never came up again.

Quoted 5 lines

Quoted 1 line
But how do I clear these structs?
Presuming that the metadata backups are intact, you need to "pvcreate -ff" the physical volumes and run vgcfgrestore on each of them. "vgscan ; vgchange -ay" should get you back to business afterwards.

Yes, I thought this would help, too. But it didn't. :-(

Commands always failed with "pv_read(): read" or "pv_read():
<something about creating names from kdev>". Because I needed my laptop back up again today I restored my backup yesterday evening, so unfortunately I can't help anymore to find out what actually happened... :-(

cu,

Raffi

Signature · 4 lines

=> Neu im Usenet? Fragen?    http://www.use-net.ch/usenet_intro_de.html <=
  The difference between theory and practice is that in theory, there is
                 no difference, but in practice, there is.
Raffael Herzog - [email protected] - http://www.raffael.ch - ICQ #67961355

Glenn Shannon

2002-10-07 05:35 UTC #3 lore raw

Was this computer connected to a network when it went down?

Looks like a stack overflow to me, but where was the originator? Coda? Unlikely but possible. Replaced syscalls usually (IIRC) indicate that not only did a stack overflow occur but also that registers were modified by whatever overflowed the stack. The kernel is noting itself as tainted, which means that some form on non-GPLed module is running (or has entered the stack to converse with the kernel directly, acting as a module..) After the initial oops it appears to cascade to the rest of the network-aware daemons, finally uprooting xfs and (presumably) b0rking the drive(s).

Just a thought I had while reading the syslog.....forgive me if anything I say is oncorrect I am by no means the kernel hacker that Heinz is :)

Glenn
--Dawn is Nature's way of telling you that it is time for bed.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Raffael Herzog
Sent: Monday, October 07, 2002 2:19 AM
To: [email protected]
Subject: Re: [linux-lvm] How to fix inconsistent LV structs?

Hi Heinz,

Quoted 3 lines · Heinz J . Mauelshagen

Hmmm...
Sounds like a nasty overwrite but it is hard to tell because you can't remmeber the exact details :(

Well, I can, the syslog is one of the only things that still exist, besides the backup... :-) These are the last few messages of the catastrophic reboot:

,----[ /var/log/syslog ]

| Oct  5 21:08:33 rumba kernel: Coda: Bye bye.
| Oct  5 21:08:33 rumba kernel: redir cleanup
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  12 [e0a01674]

with [c012e408]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 106 [e0a017a0] with [c0134ad0]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 107 [e0a0184c] with [c0134bb0]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 33 [e0a018fc] with [c012e2dc]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 5 [e0a019c0]
with [c012ecb4]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 85 [e0a01a9c] with [c0134ce0]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 183 [e0a01bd0] with [c013ef44]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 195 [e0a01d7c] with [c0134ebc]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 196 [e0a01e30] with [c0134f30]
| Oct 5 21:08:33 rumba kernel: replacing syscall nr. 11 [e0a01f4c] with [c0105a30]
| Oct 5 21:08:33 rumba kernel: Unable to handle kernel paging request at virtual address e0a019fb

| Oct  5 21:08:33 rumba kernel:  printing eip:
| Oct  5 21:08:33 rumba kernel: e0a019fb
| Oct  5 21:08:33 rumba kernel: *pde = 01870067
| Oct  5 21:08:33 rumba kernel: *pte = 00000000
| Oct  5 21:08:33 rumba kernel: Oops: 0000
| Oct  5 21:08:33 rumba kernel: CPU:    0
| Oct  5 21:08:33 rumba kernel: EIP:    0010:[<e0a019fb>]    Tainted: P 
| Oct  5 21:08:33 rumba kernel: EFLAGS: 00010286
| Oct  5 21:08:33 rumba kernel: eax: 00000005   ebx: 08094482   ecx:
d27ea3e0   edx: c1807ea0
| Oct  5 21:08:33 rumba kernel: esi: 00000241   edi: 08094482   ebp:
dcda5fbc   esp: dcda5f94
| Oct  5 21:08:33 rumba kernel: ds: 0018   es: 0018   ss: 0018
| Oct  5 21:08:33 rumba kernel: Process avfscoda (pid: 354,

stackpage=dcda5000)
| Oct 5 21:08:33 rumba kernel: Stack: 08094482 00000241 000001b6 dd27e360 dcda4000 00000241 08094482 00000001
| Oct 5 21:08:33 rumba kernel: c0141df8 c0106e0c bffff6f8
c0106d1b 08094482 00000241 000001b6 00000241
| Oct 5 21:08:33 rumba kernel: 08094482 bffff6f8 00000005
0000002b 0000002b 00000005 4017b2e4 00000023
| Oct 5 21:08:33 rumba kernel: Call Trace: [sys_oldumount+12/16] [error_code+52/60] [system_call+51/56]

| Oct  5 21:08:33 rumba kernel: 
| Oct  5 21:08:33 rumba kernel: Code:  Bad EIP value.
| Oct  5 21:08:33 rumba kernel:  <6>i8k: module unloaded
| Oct  5 21:08:35 rumba nmbd[7091]: [2002/10/05 21:08:35, 0]
nmbd/nmbd.c:sig_term(63) 
| Oct  5 21:08:35 rumba nmbd[7091]:   Got SIGTERM: going down... 
| Oct  5 21:08:35 rumba xfs[593]: terminating 
| Oct  5 21:08:35 rumba xfs[594]: terminating 
| Oct  5 21:08:35 rumba ntpd[604]: ntpd exiting on signal 15
| Oct  5 21:08:36 rumba usbmgr[12064]: umount /proc/bus/usb
| Oct  5 21:08:36 rumba rpc.statd[265]: Caught signal 15, un-registering
and exiting.
| Oct  5 21:08:36 rumba kernel: Kernel logging (proc) stopped.
| Oct  5 21:08:36 rumba kernel: Kernel log daemon terminating.
| Oct  5 21:08:36 rumba exiting on signal 15

`----

For a very short time (that laptop is *fast* :-) I've seen a message about a failed umount, then it went down and never came up again.

Quoted 3 lines

Quoted 1 line
But how do I clear these structs?
Presuming that the metadata backups are intact, you need to "pvcreate

-ff"

Quoted 2 lines

the physical volumes and run vgcfgrestore on each of them. "vgscan ; vgchange -ay" should get you back to business afterwards.

Yes, I thought this would help, too. But it didn't. :-(

cu,

Raffi

Signature · 12 lines

=> Neu im Usenet? Fragen?    http://www.use-net.ch/usenet_intro_de.html
<=
  The difference between theory and practice is that in theory, there is
                 no difference, but in practice, there is.
Raffael Herzog - [email protected] - http://www.raffael.ch - ICQ
#67961355

_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO@http://tldp.org/HOWTO/LVM-HOWTO/

Raffael Herzog

author

2002-10-07 06:32 UTC #4 lore raw

Hi Glenn,

Quoted 1 line · Glenn Shannon

Was this computer connected to a network when it went down?

Yes. I'm using the 3c95x driver.

Quoted 4 lines

Looks like a stack overflow to me, but where was the originator? Coda? Unlikely but possible. Replaced syscalls usually (IIRC) indicate that not only did a stack overflow occur but also that registers were modified by whatever overflowed the stack.

Coda always replaces Syscalls, AFAIK. At least, it does so on initialization.

Quoted 4 lines

The kernel is noting itself
as tainted, which means that some form on non-GPLed module is running (or has entered the stack to converse with the kernel directly, acting as a module..)

Correct, the nVidia driver taints the kernel.

cu,

Raffi

Signature · 4 lines

=> Neu im Usenet? Fragen?    http://www.use-net.ch/usenet_intro_de.html <=
  The difference between theory and practice is that in theory, there is
                 no difference, but in practice, there is.
Raffael Herzog - [email protected] - http://www.raffael.ch - ICQ #67961355

Heinz J . Mauelshagen

2002-10-07 06:43 UTC #5 lore raw

In reply to Raffael Herzog

Raffael,

nothing in the log directly related to LVM :(
But your hint WRT naming devices could help us.
Do you have devfs mounted on /dev and don't use the full devfs names in all cases?
If so, please retry giving the full names.

Regards,
Heinz -- The LVM Guy --

Quoted 77 lines · Raffael Herzog

Hi Heinz,

Quoted 3 lines · Heinz J . Mauelshagen

Hmmm...
Sounds like a nasty overwrite but it is hard to tell because you can't remmeber the exact details :(

Well, I can, the syslog is one of the only things that still exist, besides the backup... :-) These are the last few messages of the catastrophic reboot:

,----[ /var/log/syslog ]

| Oct  5 21:08:33 rumba kernel: Coda: Bye bye.
| Oct  5 21:08:33 rumba kernel: redir cleanup
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  12 [e0a01674] with [c012e408]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 106 [e0a017a0] with [c0134ad0]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 107 [e0a0184c] with [c0134bb0]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  33 [e0a018fc] with [c012e2dc]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.   5 [e0a019c0] with [c012ecb4]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  85 [e0a01a9c] with [c0134ce0]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 183 [e0a01bd0] with [c013ef44]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 195 [e0a01d7c] with [c0134ebc]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr. 196 [e0a01e30] with [c0134f30]
| Oct  5 21:08:33 rumba kernel: replacing syscall nr.  11 [e0a01f4c] with [c0105a30]
| Oct  5 21:08:33 rumba kernel: Unable to handle kernel paging request at virtual address e0a019fb
| Oct  5 21:08:33 rumba kernel:  printing eip:
| Oct  5 21:08:33 rumba kernel: e0a019fb
| Oct  5 21:08:33 rumba kernel: *pde = 01870067
| Oct  5 21:08:33 rumba kernel: *pte = 00000000
| Oct  5 21:08:33 rumba kernel: Oops: 0000
| Oct  5 21:08:33 rumba kernel: CPU:    0
| Oct  5 21:08:33 rumba kernel: EIP:    0010:[<e0a019fb>]    Tainted: P 
| Oct  5 21:08:33 rumba kernel: EFLAGS: 00010286
| Oct  5 21:08:33 rumba kernel: eax: 00000005   ebx: 08094482   ecx: d27ea3e0   edx: c1807ea0
| Oct  5 21:08:33 rumba kernel: esi: 00000241   edi: 08094482   ebp: dcda5fbc   esp: dcda5f94
| Oct  5 21:08:33 rumba kernel: ds: 0018   es: 0018   ss: 0018
| Oct  5 21:08:33 rumba kernel: Process avfscoda (pid: 354, stackpage=dcda5000)
| Oct  5 21:08:33 rumba kernel: Stack: 08094482 00000241 000001b6 dd27e360 dcda4000 00000241 08094482 00000001 
| Oct  5 21:08:33 rumba kernel:        c0141df8 c0106e0c bffff6f8 c0106d1b 08094482 00000241 000001b6 00000241 
| Oct  5 21:08:33 rumba kernel:        08094482 bffff6f8 00000005 0000002b 0000002b 00000005 4017b2e4 00000023 
| Oct  5 21:08:33 rumba kernel: Call Trace: [sys_oldumount+12/16] [error_code+52/60] [system_call+51/56] 
| Oct  5 21:08:33 rumba kernel: 
| Oct  5 21:08:33 rumba kernel: Code:  Bad EIP value.
| Oct  5 21:08:33 rumba kernel:  <6>i8k: module unloaded
| Oct  5 21:08:35 rumba nmbd[7091]: [2002/10/05 21:08:35, 0] nmbd/nmbd.c:sig_term(63) 
| Oct  5 21:08:35 rumba nmbd[7091]:   Got SIGTERM: going down... 
| Oct  5 21:08:35 rumba xfs[593]: terminating 
| Oct  5 21:08:35 rumba xfs[594]: terminating 
| Oct  5 21:08:35 rumba ntpd[604]: ntpd exiting on signal 15
| Oct  5 21:08:36 rumba usbmgr[12064]: umount /proc/bus/usb
| Oct  5 21:08:36 rumba rpc.statd[265]: Caught signal 15, un-registering and exiting.
| Oct  5 21:08:36 rumba kernel: Kernel logging (proc) stopped.
| Oct  5 21:08:36 rumba kernel: Kernel log daemon terminating.
| Oct  5 21:08:36 rumba exiting on signal 15

`----

For a very short time (that laptop is *fast* :-) I've seen a message about a failed umount, then it went down and never came up again.

Quoted 5 lines

Quoted 1 line
But how do I clear these structs?
Presuming that the metadata backups are intact, you need to "pvcreate -ff" the physical volumes and run vgcfgrestore on each of them. "vgscan ; vgchange -ay" should get you back to business afterwards.

Yes, I thought this would help, too. But it didn't. :-(

Quoted 16 lines

cu,

Raffi

Signature · 10 lines

=> Neu im Usenet? Fragen?    http://www.use-net.ch/usenet_intro_de.html <=
  The difference between theory and practice is that in theory, there is
                 no difference, but in practice, there is.
Raffael Herzog - [email protected] - http://www.raffael.ch - ICQ #67961355

_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Raffael Herzog

author

2002-10-07 08:40 UTC #6 lore raw

Hi Heinz,

Quoted 4 lines · Heinz J . Mauelshagen

nothing in the log directly related to LVM :(
But your hint WRT naming devices could help us.
Do you have devfs mounted on /dev and don't use the full devfs names in all cases?

I don't use devfs at all (yet), but the device nodes were present all the time. What do you mean with "full devfs names"?

Maybe these excerpts of the output of pvdata help (this is from a run after I did pvcreate -ff):

,----[ pvdata -d /dev/hda7 ]

| [...]
| <1> lv_copy_from_disk -- CALLED
| <1> lv_copy_from_disk -- LEAVING
| <1> lv_check_consistency -- CALLED
| <22> lv_check_name -- CALLED with lv_name: "HM^A"
| <333> lvm_check_chars -- CALLED with name: "HM^A"
| <333> lvm_check_chars -- LEAVING with ret: -100
| <22> lv_check_name -- LEAVING with ret: -132
| <1> lv_check_consistency -- LEAVING with ret: -149
| pvdata -- logical volume struct at offset   0 is inconsistent
| [...]
| 
| <1> lv_copy_from_disk -- CALLED
| <1> lv_copy_from_disk -- LEAVING
| <1> lv_check_consistency -- CALLED
| <22> lv_check_name -- CALLED with lv_name: ""
| <22> lv_check_name -- LEAVING with ret: -132
| <1> lv_check_consistency -- LEAVING with ret: -149
| pvdata -- logical volume struct at offset  13 is inconsistent
| <1> lv_copy_from_disk -- CALLED
| <1> lv_copy_from_disk -- LEAVING
| <1> lv_check_consistency -- CALLED
| <22> lv_check_name -- CALLED with lv_name: "ªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªª
| <22> lv_check_name -- LEAVING with ret: -132
| <1> lv_check_consistency -- LEAVING with ret: -149
| pvdata -- logical volume struct at offset  14 is inconsistent
| [...]
| 
| <1> lv_copy_from_disk -- CALLED
| <1> lv_copy_from_disk -- LEAVING
| --- NEW Physical volume ---
| PV Name               /dev/hda7
| VG Name               
| PV Size               32.44 GB [68035212 secs]
| PV#                   0
| PV Status             NOT available
| Allocatable           NO
| Cur LV                0
| PE Size (KByte)       0
| Total PE              0
| Free PE               0
| Allocated PE          0
| PV UUID               0KMQsG-r21J-GwKA-qpZD-1FC9-plP0-t0aryJ
| 
| --- Volume group ---
| VG Name               
| VG Access             read/write
| VG Status             NOT available/resizable
| VG #                  0
| MAX LV                256
| Cur LV                3
| Open LV               0
| MAX LV Size           255.99 GB
| Max PV                256
| Cur PV                1
| Act PV                1
| VG Size               32.44 GB
| PE Size               4 MB
| Total PE              8304
| Alloc PE / Size       4375 / 17.09 GB
| Free  PE / Size       3929 / 15.35 GB
| VG UUID               BC9DHB-T9v3-6LNt-7qtv-7uHE-7pg2-K4flga
| 
| --- List of logical volumes ---
| 
| pvdata -- logical volume struct at offset   1 is empty
| [...]
| <1> lv_copy_from_disk -- CALLED
| <1> lv_copy_from_disk -- LEAVING
| <1> lv_check_consistency -- CALLED
| <22> lv_check_name -- CALLED with lv_name: "ªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªª
| <22> lv_check_name -- LEAVING with ret: -132
| <1> lv_check_consistency -- LEAVING with ret: -149
| pvdata -- logical volume struct at offset 125 is inconsistent
| [like this through to LV 139]
| [...]
| 
| <1> lv_copy_from_disk -- CALLED
| <1> lv_copy_from_disk -- LEAVING
| <1> pv_read_uuidlist -- CALLED with /dev/hda7
| <1> pv_read_uuidlist -- LEAVING with ret: 0
| <1> lvm_check_uuid -- CALLED with uuidstr: "(null)"
| <1> lvm_check_uuid -- LEAVING with ret: -1
| 
| Segmentation fault.

`----

So you see, there was really a lot of garbage... :-)

I also saved the outputs of pvscan -d and vgscan -d, in case you think they help.

Quoted 1 line

If so, please retry giving the full names.

I can't try anything anymore because I decided not to use LVM anymore at least until I know what happened and I know that it won't happen again. Sure, it's probably not the fault of LVM, but I think, if I would have been using "plain ext2/3", I probably wouldn't have lost just *all* of my data (lucky that I had a very young backup, so I actually didn't loose anything).

cu,

Raffi

Signature · 4 lines

=> Neu im Usenet? Fragen?    http://www.use-net.ch/usenet_intro_de.html <=
  The difference between theory and practice is that in theory, there is
                 no difference, but in practice, there is.
Raffael Herzog - [email protected] - http://www.raffael.ch - ICQ #67961355

Heinz J . Mauelshagen

2002-10-09 06:24 UTC #7 lore raw

Quoted 4 lines · Raffael Herzog

Hi Heinz,
Heinz J . Mauelshagen wrote:

Quoted 8 lines

Quoted 4 lines
nothing in the log directly related to LVM :(
But your hint WRT naming devices could help us.
Do you have devfs mounted on /dev and don't use the full devfs names in all cases?
I don't use devfs at all (yet), but the device nodes were present all the time. What do you mean with "full devfs names"?

I meant nasty devfs names like /dev/scsi/host0/bus0/target0/lun0/part1 ;)

But as you say, you don't use it, which brings us back to the overwrite assumption and the necessary vgcfgrestore's.

I recommend to save the metadata of all PVs belonging to the gone VG for potential later analysis with "dd if=/dev/PV of=PV.vgda bs=1k count=4k". Insert all your PVs (say AllPVs) in sequence for "PV"
(i.e. for PV in AllPVs; do dd if=/dev/$PV of=${PV}.vgda bs=1k count=4k;done).

The procedure to restore your metadata to all those PVs goes:

- run "pvcreate -yff AllPVs"
- run "for PV in AllPVs;do vgcfgrestore -n NameOfTheVG /dev/$PV;done"
- run "vgscan ; vgchange -ay"

Should be it...

Quoted 9 lines

Maybe these excerpts of the output of pvdata help (this is from a run after I did pvcreate -ff):
,----[ pvdata -d /dev/hda7 ]
| [...]
| <1> lv_copy_from_disk -- CALLED
| <1> lv_copy_from_disk -- LEAVING
| <1> lv_check_consistency -- CALLED

<SNIP>

Quoted 3 lines

`----
So you see, there was really a lot of garbage... :-)

Was likely if overwriten.

Quoted 3 lines

I also saved the outputs of pvscan -d and vgscan -d, in case you think they help.

Well, they should just harden the garbage ;)

Quoted 11 lines

Quoted 3 lines
If so, please retry giving the full names.
I can't try anything anymore because I decided not to use LVM anymore at least until I know what happened and I know that it won't happen again. Sure, it's probably not the fault of LVM, but I think, if I would have been using "plain ext2/3", I probably wouldn't have lost just *all* of my data (lucky that I had a very young backup, so I actually didn't loose anything).

That depends on the nature of the overwrite. Could at least kill a filesystem if enough is written to the device.

Regards,
Heinz -- The LVM Guy --

Quoted 17 lines

cu,

Raffi

Signature · 10 lines

=> Neu im Usenet? Fragen?    http://www.use-net.ch/usenet_intro_de.html <=
  The difference between theory and practice is that in theory, there is
                 no difference, but in practice, there is.
Raffael Herzog - [email protected] - http://www.raffael.ch - ICQ #67961355

_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-