vgcfgrestore fails.
Quoted 39 lines · root
I am running SuSe 7.1
2.4.0 kernel
512M Ram
AhA2940U2W
suse lvmI had three volume groups and a week ago the volume group that contained user had a drive crash. I was unable to save usr but now I can not mount any of my other volume groups and vgcfgrestore fails. Is their any thing I can do to get my data?
thor:~ # pvdisplay/dev/sdd2
--- Physical volume ---PV Name /dev/sdd2 VG Name export PV Size 8.3 GB / NOT usable 3.31 MB [LVM: 238 KB] PV# 2 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 2123 Free PE 0 Allocated PE 2123 PV UUID ruLId0-1JoY-34Ja-oLW0-FmzV-Q5ZN-NQaZw9 thor:~ # pvdisplay /dev/sdc2 --- Physical volume --- PV Name /dev/sdc2 VG Name export PV Size 8.3 GB / NOT usable 3.31 MB [LVM: 238 KB] PV# 1 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 2123 Free PE 0 Allocated PE 2123 PV UUID ynnKCX-mjlT-jeNe-9MHY-tnP2-XCIC-nbKrmq
Quoted 5 lines
thor:~ # vgcfgrestore -n export
/dev/sdd2
vgcfgrestore -- ERROR: different structure size stored in "/etc/lvmconf/export.conf" than expected in filevg_cfgrestore.c[line 122]
vgcfgrestore -- ERROR "vg_cfgrestore(): read" restoring volume group "export"
You are using a newer LVM versions which has different metadata definitions that the one which created those backups.
My guess is, that you are using LVM > 0.9.1 Beta 3 *now* but created the backups with a lower LVM 0.9 version and you suffer from a PV uuid related bug preventing vgscan to find your VG.
One way to address the situation (pressuming no VGs are active) is:
- create /etc/lvmtab.d/ in case it doesn't exist
- copy /etc/lvmconf/export.conf to /etc/lvmtab.d/export
- echo -ne 'export\0' > /etc/lvmtab
- vgchange -ay
If the VG named "export" comes back to life this way (assuming that the user LV belongs to it) do:
- lvreduce -l1 /dev/export/user
- lvrextend -l1 /dev/export/user
replace "user" with a valid LV name in case I assumed wrong.
The purpose of that NULL operation in the end is, that your PV uuid list gets recreated by LVM >= 0.9.1 Beta 4 which should make vgscan happy again ;-)
The last 2 commands just shrink user by 1 LE and grow it again which is necessary, because your export VG is *full*. This will not harm the user LV in the end, because the allocator has the only option to use the very same PE for growing which was freed before by the shrinking of user.
If your VG had at least 1 free PE a lvcreate/lvremove cycle for a dummy LV with just 1 LE had done it as well.
Please tell us if this helps you or we need to go for another solution.
Quoted 5 lines
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-No joy on this on this method.
If you need I can supply more inforamation.
BTW I am running on an Athlon..
thor:/etc # cp /etc/lvmconf/export.conf /etc/lvmtab.d/export thor:/etc # cp /etc/lvmconf/opt.conf /etc/lvmtab.d/opt
thor:/etc # echo -ne "export\0" > /etc/lvmtab
thor:/etc # echo -ne "opt\0" >> /etc/lvmtab
thor:/etc # vgchange -ay
vgchange -- ERROR: different structure size stored in "/etc/lvmtab.d/export" than expected in file vg_cfgrestore.c [line 122]
vgchange -- volume group "export" does not exist
vgchange -- ERROR: different structure size stored in "/etc/lvmtab.d/opt" than expected in file vg_cfgrestore.c [line 122]
vgchange -- volume group "opt" does not exist
Quoted 91 lines · you
Quoted 39 lines · root
I am running SuSe 7.1
2.4.0 kernel
512M Ram
AhA2940U2W
suse lvmI had three volume groups and a week ago the volume group that contained user had a drive crash. I was unable to save usr but now I can not mount any of my other volume groups and vgcfgrestore fails. Is their any thing I can do to get my data?
thor:~ # pvdisplay/dev/sdd2
--- Physical volume ---PV Name /dev/sdd2 VG Name export PV Size 8.3 GB / NOT usable 3.31 MB [LVM: 238 KB] PV# 2 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 2123 Free PE 0 Allocated PE 2123 PV UUID ruLId0-1JoY-34Ja-oLW0-FmzV-Q5ZN-NQaZw9 thor:~ # pvdisplay /dev/sdc2 --- Physical volume --- PV Name /dev/sdc2 VG Name export PV Size 8.3 GB / NOT usable 3.31 MB [LVM: 238 KB] PV# 1 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 2123 Free PE 0 Allocated PE 2123 PV UUID ynnKCX-mjlT-jeNe-9MHY-tnP2-XCIC-nbKrmqQuoted 6 lines
thor:~ # vgcfgrestore -n export
/dev/sdd2
vgcfgrestore -- ERROR: different structure size stored in "/etc/lvmconf/export.conf" than expected in filevg_cfgrestore.c[line 122]
vgcfgrestore -- ERROR "vg_cfgrestore(): read" restoring volume group "export"You are using a newer LVM versions which has different metadata definitions that the one which created those backups.
My guess is, that you are using LVM > 0.9.1 Beta 3 *now* but created the backups with a lower LVM 0.9 version and you suffer from a PV uuid related bug preventing vgscan to find your VG.
One way to address the situation (pressuming no VGs are active) is:
- create
/etc/lvmtab.d/in case it doesn't exist- copy
/etc/lvmconf/export.confto/etc/lvmtab.d/export- echo -ne 'export\0' >
/etc/lvmtab- vgchange -ay
If the VG named "export" comes back to life this way (assuming that the user LV belongs to it) do:
- lvreduce -l1
/dev/export/user
- lvrextend -l1/dev/export/userreplace "user" with a valid LV name in case I assumed wrong.
The purpose of that NULL operation in the end is, that your PV uuid list gets recreated by LVM >= 0.9.1 Beta 4 which should make vgscan happy again ;-)
The last 2 commands just shrink user by 1 LE and grow it again which is necessary, because your export VG is *full*. This will not harm the user LV in the end, because the allocator has the only option to use the very same PE for growing which was freed before by the shrinking of user.
If your VG had at least 1 free PE a lvcreate/lvremove cycle for a dummy LV with just 1 LE had done it as well.
Please tell us if this helps you or we need to go for another solution.
Quoted 4 lines
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
Ok, I have my volumes back.
It was messy but it worked.
l simply removed the lvm 9.4 and reinstalled lvm 8.0 I then did the vgcfgrestore and opt and export came back. thanks for your help.
Quoted 112 lines · you
No joy on this on this method.
If you need I can supply more inforamation.
BTW I am running on an Athlon..
thor:/etc # cp/etc/lvmconf/export.conf/etc/lvmtab.d/exportthor:/etc # cp/etc/lvmconf/opt.conf/etc/lvmtab.d/optthor:/etc # echo -ne "export\0" >/etc/lvmtab
thor:/etc # echo -ne "opt\0" >>/etc/lvmtab
thor:/etc # vgchange -ay
vgchange -- ERROR: different structure size stored in "/etc/lvmtab.d/export" than expected in filevg_cfgrestore.c[line 122] vgchange -- volume group "export" does not exist
vgchange -- ERROR: different structure size stored in "/etc/lvmtab.d/opt" than expected in filevg_cfgrestore.c[line 122]
vgchange -- volume group "opt" does not existQuoted 82 lines · you
Quoted 39 lines · root
I am running SuSe 7.1
2.4.0 kernel
512M Ram
AhA2940U2W
suse lvmI had three volume groups and a week ago the volume group that contained user had a drive crash. I was unable to save usr but now I can not mount any of my other volume groups and vgcfgrestore fails. Is their any thing I can do to get my data?
thor:~ # pvdisplay/dev/sdd2
--- Physical volume ---PV Name /dev/sdd2 VG Name export PV Size 8.3 GB / NOT usable 3.31 MB [LVM: 238 KB] PV# 2 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 2123 Free PE 0 Allocated PE 2123 PV UUID ruLId0-1JoY-34Ja-oLW0-FmzV-Q5ZN-NQaZw9 thor:~ # pvdisplay /dev/sdc2 --- Physical volume --- PV Name /dev/sdc2 VG Name export PV Size 8.3 GB / NOT usable 3.31 MB [LVM: 238 KB] PV# 1 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 2123 Free PE 0 Allocated PE 2123 PV UUID ynnKCX-mjlT-jeNe-9MHY-tnP2-XCIC-nbKrmqQuoted 6 lines
thor:~ # vgcfgrestore -n export
/dev/sdd2
vgcfgrestore -- ERROR: different structure size stored in "/etc/lvmconf/export.conf" than expected in filevg_cfgrestore.c[line 122]
vgcfgrestore -- ERROR "vg_cfgrestore(): read" restoring volume group "export"You are using a newer LVM versions which has different metadata definitions that the one which created those backups.
My guess is, that you are using LVM > 0.9.1 Beta 3 *now* but created the backups with a lower LVM 0.9 version and you suffer from a PV uuid related bug preventing vgscan to find your VG.
One way to address the situation (pressuming no VGs are active) is:
- create
/etc/lvmtab.d/in case it doesn't exist- copy
/etc/lvmconf/export.confto/etc/lvmtab.d/export- echo -ne 'export\0' >
/etc/lvmtab- vgchange -ay
If the VG named "export" comes back to life this way (assuming that the user LV belongs to it) do:
- lvreduce -l1
/dev/export/user
- lvrextend -l1/dev/export/userreplace "user" with a valid LV name in case I assumed wrong.
The purpose of that NULL operation in the end is, that your PV uuid list gets recreated by LVM >= 0.9.1 Beta 4 which should make vgscan happy again ;-)
The last 2 commands just shrink user by 1 LE and grow it again which is necessary, because your export VG is *full*. This will not harm the user LV in the end, because the allocator has the only option to use the very same PE for growing which was freed before by the shrinking of user.
Quoted 9 lines
If your VG had at least 1 free PE a lvcreate/lvremove cycle for a dummy LV with just 1 LE had done it as well.
Please tell us if this helps you or we need to go for another solution.
Quoted 4 lines
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
Quoted 2 lines · Hcd
Ok, I have my volumes back.
It was messy but it worked.
:-(
Quoted 3 lines
l simply removed the lvm 9.4 and reinstalled lvm 8.0 I then did the vgcfgrestore and opt and export came back.
That was another option ;-)
Have you beann able to upgrade to LVM 0.9.1 Beta 7 already, run some changing command and did everything work fine?
If not so, I'ld be very interested in it.
Regards,
Heinz -- The LVM Guy --
Quoted 27 lines
thanks for your help.
Quoted 24 lines · you
No joy on this on this method.
If you need I can supply more inforamation.
BTW I am running on an Athlon..
thor:/etc # cp/etc/lvmconf/export.conf/etc/lvmtab.d/exportthor:/etc # cp/etc/lvmconf/opt.conf/etc/lvmtab.d/optthor:/etc # echo -ne "export\0" >/etc/lvmtab
thor:/etc # echo -ne "opt\0" >>/etc/lvmtab
thor:/etc # vgchange -ay
vgchange -- ERROR: different structure size stored in "/etc/lvmtab.d/export" than expected in filevg_cfgrestore.c[line 122] vgchange -- volume group "export" does not exist
vgchange -- ERROR: different structure size stored in "/etc/lvmtab.d/opt" than expected in filevg_cfgrestore.c[line 122]
vgchange -- volume group "opt" does not existQuoted 8 lines · you
Quoted 7 lines · root
I am running SuSe 7.1
2.4.0 kernel
512M Ram
AhA2940U2W
suse lvmI had three volume groups and a week ago the volume group that
<SNIP>
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
LV with just 1 LE had done it as well.
Please tell us if this helps you or we need to go for another solution.
Quoted 4 lines
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
Quoted 8 lines
Quoted 4 lines
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-