* [linux-lvm] Vgscan problem
@ 2000-04-07 18:31 Patrick Boutilier
2000-04-07 21:57 ` Heinz Mauelshagen
0 siblings, 1 reply; 6+ messages in thread
From: Patrick Boutilier @ 2000-04-07 18:31 UTC (permalink / raw)
To: linux-lvm
I am getting the following EROR -364 when running vgscan. The volume
group and logical volumes are actually in use and reiser filesystems
mounted on them.
Should I be able to run vgscan when the vg is active? If so what could
the problem be? The machine was rebooted 15 days agao with 2.2.15pre17
and vgscan worked fine then. I ran accross the problem today when I was
trying to run lvm-viewer which runs vgscan when it starts.
Thanks.
vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- scanning for all active volume group(s) first
vgscan -- found active volume group "data_vg"
vgscan -- reading data of volume group "data_vg" from physical volume(s)
vgscan -- ERROR -364: can't get data of volume group "data_vg" from
physical volume(s)
vgscan -- ERROR -364 creating "/etc/lvmtab" and "/etc/lvmtab.d"
--- Volume group ---
VG Name data_vg
VG Access read/write
VG Status NOT available/resizable
VG # 0
MAX LV 256
Cur LV 6
Open LV 0
MAX LV Size 255.99 GB
Max PV 256
Cur PV 1
Act PV 1
VG Size 133.36 GB
PE Size 4 MB
Total PE 34140
Alloc PE / Size 27125 / 105.96 GB
Free PE / Size 7015 / 27.4 GB
vg_show -- LEAVING
pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
pv_read_all_pv_of_vg -- LEAVING with ret: 0
vg_read_with_pv_and_lv -- AFTER pv_read_all_pv_of_vg
pv_read_all_pe_of_vg -- CALLED
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
pv_read_all_pv_of_vg -- LEAVING with ret: 0
pv_read_all_pe_of_vg -- pv_count: 1
pv_read_pe -- CALLED with /dev/sda7 and 34140
pv_check_name -- CALLED
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
pv_check_name -- CALLED pv_name: "/dev/sda7"
pv_check_name -- LEAVING with ret: 0
pe_copy_from_disk -- CALLED
pe_copy_from_disk -- LEAVING
pv_read_pe -- ret: 0
pv_read_pe -- LEAVING with ret: 0
pv_read_all_pe_of_vg -- /dev/sda7 with 34140 PE at address 8071258
pv_check_number -- CALLED
pv_check_number -- LEAVING with ret: 0
pv_read_all_pe_of_vg -- AFTER LOOP of pv_read_pe
pv_read_all_pe_of_vg -- /dev/sda7 with 34140 PE at address 40151008 for
PV #0
pv_read_all_pe_of_vg -- LEAVING with ret: 0
vg_read_with_pv_and_lv -- AFTER pv_read_all_pe_of_vg
lv_read_all_lv_of_vg -- CALLED
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
vg_read -- CALLED
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
pv_read_all_pv_of_vg -- LEAVING with ret: 0
vg_read -- pv[0]->pv_name: "/dev/sda7"
vg_copy_from_disk -- CALLED
vg_copy_from_disk -- LEAVING
vg_read -- LEAVING with ret: 0
lv_read_all_lv_of_vg -- lv_max: 256
lv_read_all_lv_of_vg -- BEFORE pv_read_all_pv_of_vg
pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
pv_read_all_pv_of_vg -- LEAVING with ret: 0
lv_copy_from_disk -- CALLED
lv_copy_from_disk -- LEAVING
lv_copy_from_disk -- CALLED
lv_copy_from_disk -- LEAVING
lv_copy_from_disk -- CALLED
lv_copy_from_disk -- LEAVING
lv_copy_from_disk -- CALLED
lv_copy_from_disk -- LEAVING
lv_copy_from_disk -- CALLED
lv_copy_from_disk -- LEAVING
lv_copy_from_disk -- CALLED
lv_copy_from_disk -- LEAVING
lv_read_all_lv_of_vg -- l: 256 nl: 6 vg_this->lv_cur: 6
lv_read_all_lv_of_vg -- LEAVING with ret: 0
vg_read_with_pv_and_lv -- AFTER lv_read_all_lv_of_vg; vg_this->pv_cur:
1 vg_this->pv_max: 256 ret: 0
vg_read_with_pv_and_lv -- BEFORE for PE
vg_read_with_pv_and_lv -- AFTER for PE
vg_read_with_pv_and_lv -- BEFORE for LV
vg_read_with_pv_and_lv -- vg_this->lv[0]->lv_allocated_le: 5000
vg_read_with_pv_and_lv -- vg_this->lv[1]->lv_allocated_le: 5000
vg_read_with_pv_and_lv -- vg_this->lv[2]->lv_allocated_le: 6250
vg_read_with_pv_and_lv -- vg_this->lv[3]->lv_allocated_le: 5000
vg_read_with_pv_and_lv -- vg_this->lv[4]->lv_allocated_le: 875
vg_read_with_pv_and_lv -- vg_this->lv[5]->lv_allocated_le: 1
vg_check_active -- CALLED
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
vg_status -- CALLED
vg_check_name -- CALLED
vg_check_name -- vg_name: "data_vg"
lvm_check_chars -- CALLED
lvm_check_chars -- LEAVING
vg_check_name -- LEAVING with ret: 0
vg_status -- LEAVING
vg_check_active -- LEAVING
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Vgscan problem
2000-04-07 18:31 [linux-lvm] Vgscan problem Patrick Boutilier
@ 2000-04-07 21:57 ` Heinz Mauelshagen
2000-04-08 11:09 ` Patrick Boutilier
0 siblings, 1 reply; 6+ messages in thread
From: Heinz Mauelshagen @ 2000-04-07 21:57 UTC (permalink / raw)
To: Patrick Boutilier; +Cc: mge, linux-lvm
Hi Patrick,
the error number tells you that the amount of logical extents found in
the mapping tables for e specific logical volumes differs from the
amount expected -> metedata inconsistency.
Could you provide a complete "vgscan -d" output to better anaylze this?
In the meantime please save your /etc/lvmconf/ VGDA backup files to
enable you to restore a consistent state of your VGDAs to the PVs.
Please read vgcfgrestore(8) for this issue.
Heinz
> I am getting the following EROR -364 when running vgscan. The volume
> group and logical volumes are actually in use and reiser filesystems
> mounted on them.
>
> Should I be able to run vgscan when the vg is active? If so what could
> the problem be? The machine was rebooted 15 days agao with 2.2.15pre17
> and vgscan worked fine then. I ran accross the problem today when I was
> trying to run lvm-viewer which runs vgscan when it starts.
>
> Thanks.
>
>
> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- scanning for all active volume group(s) first
> vgscan -- found active volume group "data_vg"
> vgscan -- reading data of volume group "data_vg" from physical volume(s)
>
> vgscan -- ERROR -364: can't get data of volume group "data_vg" from
> physical volume(s)
> vgscan -- ERROR -364 creating "/etc/lvmtab" and "/etc/lvmtab.d"
>
>
>
> --- Volume group ---
> VG Name data_vg
> VG Access read/write
> VG Status NOT available/resizable
> VG # 0
> MAX LV 256
> Cur LV 6
> Open LV 0
> MAX LV Size 255.99 GB
> Max PV 256
> Cur PV 1
> Act PV 1
> VG Size 133.36 GB
> PE Size 4 MB
> Total PE 34140
> Alloc PE / Size 27125 / 105.96 GB
> Free PE / Size 7015 / 27.4 GB
> vg_show -- LEAVING
> pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> pv_read_all_pv_of_vg -- LEAVING with ret: 0
> vg_read_with_pv_and_lv -- AFTER pv_read_all_pv_of_vg
> pv_read_all_pe_of_vg -- CALLED
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> pv_read_all_pv_of_vg -- LEAVING with ret: 0
> pv_read_all_pe_of_vg -- pv_count: 1
> pv_read_pe -- CALLED with /dev/sda7 and 34140
> pv_check_name -- CALLED
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> pv_check_name -- CALLED pv_name: "/dev/sda7"
> pv_check_name -- LEAVING with ret: 0
> pe_copy_from_disk -- CALLED
> pe_copy_from_disk -- LEAVING
> pv_read_pe -- ret: 0
> pv_read_pe -- LEAVING with ret: 0
> pv_read_all_pe_of_vg -- /dev/sda7 with 34140 PE at address 8071258
> pv_check_number -- CALLED
> pv_check_number -- LEAVING with ret: 0
> pv_read_all_pe_of_vg -- AFTER LOOP of pv_read_pe
> pv_read_all_pe_of_vg -- /dev/sda7 with 34140 PE at address 40151008 for
> PV #0
> pv_read_all_pe_of_vg -- LEAVING with ret: 0
> vg_read_with_pv_and_lv -- AFTER pv_read_all_pe_of_vg
> lv_read_all_lv_of_vg -- CALLED
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> vg_read -- CALLED
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> pv_read_all_pv_of_vg -- LEAVING with ret: 0
> vg_read -- pv[0]->pv_name: "/dev/sda7"
> vg_copy_from_disk -- CALLED
> vg_copy_from_disk -- LEAVING
> vg_read -- LEAVING with ret: 0
> lv_read_all_lv_of_vg -- lv_max: 256
> lv_read_all_lv_of_vg -- BEFORE pv_read_all_pv_of_vg
> pv_read_all_pv_of_vg -- CALLED with vg_name: "data_vg"
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> pv_read_all_pv_of_vg -- LEAVING with ret: 0
> lv_copy_from_disk -- CALLED
> lv_copy_from_disk -- LEAVING
> lv_copy_from_disk -- CALLED
> lv_copy_from_disk -- LEAVING
> lv_copy_from_disk -- CALLED
> lv_copy_from_disk -- LEAVING
> lv_copy_from_disk -- CALLED
> lv_copy_from_disk -- LEAVING
> lv_copy_from_disk -- CALLED
> lv_copy_from_disk -- LEAVING
> lv_copy_from_disk -- CALLED
> lv_copy_from_disk -- LEAVING
> lv_read_all_lv_of_vg -- l: 256 nl: 6 vg_this->lv_cur: 6
> lv_read_all_lv_of_vg -- LEAVING with ret: 0
> vg_read_with_pv_and_lv -- AFTER lv_read_all_lv_of_vg; vg_this->pv_cur:
> 1 vg_this->pv_max: 256 ret: 0
> vg_read_with_pv_and_lv -- BEFORE for PE
> vg_read_with_pv_and_lv -- AFTER for PE
> vg_read_with_pv_and_lv -- BEFORE for LV
> vg_read_with_pv_and_lv -- vg_this->lv[0]->lv_allocated_le: 5000
> vg_read_with_pv_and_lv -- vg_this->lv[1]->lv_allocated_le: 5000
> vg_read_with_pv_and_lv -- vg_this->lv[2]->lv_allocated_le: 6250
> vg_read_with_pv_and_lv -- vg_this->lv[3]->lv_allocated_le: 5000
> vg_read_with_pv_and_lv -- vg_this->lv[4]->lv_allocated_le: 875
> vg_read_with_pv_and_lv -- vg_this->lv[5]->lv_allocated_le: 1
> vg_check_active -- CALLED
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> vg_status -- CALLED
> vg_check_name -- CALLED
> vg_check_name -- vg_name: "data_vg"
> lvm_check_chars -- CALLED
> lvm_check_chars -- LEAVING
> vg_check_name -- LEAVING with ret: 0
> vg_status -- LEAVING
> vg_check_active -- LEAVING
>
>
>
>
>
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
S_ystemmanagement TS T-Nova
Entwicklungszentrum Darmstadt
Heinz Mauelshagen Otto-Roehm-Strasse 71c
Senior Systems Engineer Postfach 10 05 41
64205 Darmstadt
mge@EZ-Darmstadt.Telekom.de Germany
+49 6151 886-425
FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Vgscan problem
2000-04-07 21:57 ` Heinz Mauelshagen
@ 2000-04-08 11:09 ` Patrick Boutilier
0 siblings, 0 replies; 6+ messages in thread
From: Patrick Boutilier @ 2000-04-08 11:09 UTC (permalink / raw)
To: Heinz Mauelshagen; +Cc: macleajb, linux-lvm
Heinz,
I think I may know how I caused my problem. Do you think this may be the cause of
the problem?
I have /dev/data_vg shown below:
--- Volume group ---
VG Name data_vg
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 6
Open LV 5
MAX LV Size 255.99 GB
Max PV 256
Cur PV 1
Act PV 1
VG Size 133.36 GB
PE Size 4 MB
Total PE 34140
Alloc PE / Size 27125 / 105.96 GB
Free PE / Size 7015 / 27.4 GB
Here is the info for the PV:
--- Physical volume ---
PV Name /dev/sda7
VG Name data_vg
PV Size 133.36 GB / NOT usable 321 KB [LVM: 255 KB]
PV# 1
PV Status available
Allocatable yes
Cur LV 6
PE Size (KByte) 4096
Total PE 34140
Free PE 7015
Allocated PE 27125
/dev/sda is actually a RAID 5 array of 5 x 36 Gig drives on a Dell Perc2/SC (AMI
Megatrends).
The 6 LVs are /dev/data_vg/home_lv, /dev/data_vg/var_lv, /dev/data_vg/usr_lv,
/dev/data_vg/news_lv, /dev/data_vg/its_lv, and /dev/data_vg/test_lv All LV are
19.53 Gig in size except test_lv which is 3.42 Gig
I think my problem arose on April 3rd when I created /dev/data_vg/its_lv and
mounted it as /usr/local/its The problem here is that /dev/data_vg/usr_lv is
mounted as /usr I then moved/rsynced /usr/local/vmware/* (on usr_lv) to
/usr/local/its/vmware/* (on its_lv)
So I am thinking that mounting a LV inside another LV and moving data is probably
what messed me up. Does this make any sense?
To get out of this mess I am thinking of using this scenario. I now have
/dev/data_vg/its_lv mounted as /data of the / which is not part of any LV. I have
this file from /etc/lvmconf which is the latest file before April 3rd when I made
the changes.
579300 Feb 23 15:36 data_vg.conf.4.old
vgcfgrestore -t -f /etc/lvmconf/data_vg.conf.4.old -n data_vg -l shows this:
-- Volume group ---
VG Name data_vg
VG Access read/write
VG Status NOT available/resizable
VG # 0
MAX LV 256
Cur LV 5
Open LV 0
MAX LV Size 255.99 GB
Max PV 256
Cur PV 1
Act PV 1
VG Size 133.36 GB
PE Size 4 MB
Total PE 34140
Alloc PE / Size 22125 / 86.43 GB
Free PE / Size 12015 / 46.93 GB
That would give me the 5 LVs without /dev/data_vg/its_lv
I would then backup the data on /dev/data_vg/its_lv and then use this command to
restore the VGDA?
vgcfgrestore -f /etc/lvmconf/data_vg.conf.4.old -n data_vg
If so would I need to delete the /dev/data_vg/its_lv before running the previous
command or would it matter?
Thanks for your help.
Heinz Mauelshagen wrote:
> Hi Patrick,
>
> the error number tells you that the amount of logical extents found in
> the mapping tables for e specific logical volumes differs from the
> amount expected -> metedata inconsistency.
>
> Could you provide a complete "vgscan -d" output to better anaylze this?
>
> In the meantime please save your /etc/lvmconf/ VGDA backup files to
> enable you to restore a consistent state of your VGDAs to the PVs.
> Please read vgcfgrestore(8) for this issue.
>
> Heinz
>
> > I am getting the following EROR -364 when running vgscan. The volume
> > group and logical volumes are actually in use and reiser filesystems
> > mounted on them.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [linux-lvm] vgscan problem
@ 2002-01-06 19:29 Andrew Schaefer
2002-01-15 8:30 ` Heinz J . Mauelshagen
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Schaefer @ 2002-01-06 19:29 UTC (permalink / raw)
To: linux-lvm
I just setup LVM with two disks in the volume group big_space. I started
out with one disk and then extended it across the other. It
formatted, fs extended, and mounted up fine. I then rebooted, and now I
get this error from vgscan:
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found inactive volume group "big_space"
vgscan -- ERROR "pv_read_pe(): read" can't get data of volume group
"big_space"
from physical volume(s)
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume
group
Any ideas or suggestions? Unfortunately I threw data onto the volume and
don't want to loose it.
Andrew Schaefer
andrew@schaefer.nu
http://www.schaefer.nu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] vgscan problem
2002-01-06 19:29 [linux-lvm] vgscan problem Andrew Schaefer
@ 2002-01-15 8:30 ` Heinz J . Mauelshagen
0 siblings, 0 replies; 6+ messages in thread
From: Heinz J . Mauelshagen @ 2002-01-15 8:30 UTC (permalink / raw)
To: linux-lvm
Andrew,
so you did pvcreate the second PV and added (vgextend) it to your existing
VG successfully?
What exactly happened before vgscan complained?
You should have a valid LVM metadata backup in /etc/lvmconf/big_space.conf
(or an older copy named /etc/lvmconf/big_space.conf.#.old where # is a number
from 1 up to 9).
To figure out which one is ok you want to for eg. use
vgcfgrestore -n big_space -f /etc/lvmconf/big_space.conf -ll
To restore the metadata run:
pvcreate -ff /dev/BothOfYourPVs
vgcfgrestore -n big_space -f /etc/lvmconf/big_space.conf /dev/Your1stPV
vgcfgrestore -n big_space -f /etc/lvmconf/big_space.conf /dev/Your2ndPV
vgscan
On Sun, Jan 06, 2002 at 08:32:09PM -0500, Andrew Schaefer wrote:
> I just setup LVM with two disks in the volume group big_space. I started
> out with one disk and then extended it across the other. It
> formatted, fs extended, and mounted up fine. I then rebooted, and now I
> get this error from vgscan:
>
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- found inactive volume group "big_space"
> vgscan -- ERROR "pv_read_pe(): read" can't get data of volume group
> "big_space"
> from physical volume(s)
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> vgscan -- WARNING: This program does not do a VGDA backup of your volume
> group
>
> Any ideas or suggestions? Unfortunately I threw data onto the volume and
> don't want to loose it.
>
> Andrew Schaefer
> andrew@schaefer.nu
> http://www.schaefer.nu
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
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
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] vgscan problem
2003-04-30 21:12 ` Duane Evenson
@ 2003-05-02 22:29 ` Duane Evenson
0 siblings, 0 replies; 6+ messages in thread
From: Duane Evenson @ 2003-05-02 22:29 UTC (permalink / raw)
To: linux-lvm
A little more information:
I looked at the metadata using
od -v -A x -t x1z /dev/hde|more
and the UUID shown in pvscan
is at 0x1e00, I get something else at 0x1000:
000fe0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
000ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
001000 c1 c0 e0 04 24 10 0c a0 80 e5 0f 0a c5 51 8b 0e >....$........Q..<
001010 92 25 d1 e1 e2 fe 59 ee 42 b0 20 51 8b 0e 92 25 >.%....Y.B. Q...%<
001020 d1 e1 e2 fe 59 ee 51 8b 0e 92 25 d1 e1 e2 fe 59 >....Y.Q...%....Y<
...
001df0 e9 c0 fa c6 06 18 25 20 90 e9 4c fa b0 b0 f7 06 >......% ..L.....<
001e00 78 31 6c 32 61 32 58 55 7a 58 58 45 6a 5a 68 50 >x1l2a2XUzXXEjZhP<
001e10 33 6b 71 41 6d 6f 47 35 6a 48 55 31 7a 31 43 38 >3kqAmoG5jHU1z1C8<
001e20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
001e30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
Is this the problem?
Duane Evenson wrote:
> pvscan only finds hde -- good, as that's all it should.
> ...so I did as you suggested: pvcreate -ff /dev/hde; vgcfgrestore -n
> data_group /dev/hde; vgscan returned:
> #vgscan
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- ERROR "vg_read_with_pv_and_lv(): current PV" can't get data
> of volume
> group "data_group" from physical volume(s)
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> vgscan -- WARNING: This program does not do a VGDA backup of your
> volume group
>
> I think this is the same problem as before.
> There exists /etc/lvmconf/data_group.conf and
> /etc/lvmconf/data_group.conf.1.old. Testing this volume group
> descriptor data:
> # vgcfgrestore -t -l -n data_group /dev/hde
> vgcfgrestore -- INFO: using backup file "/etc/lvmconf/data_group.conf"
> vgcfgrestore -- backup of volume group "data_group" is consistent
> --- Volume group ---
> VG Name data_group
> VG Access read/write
> VG Status NOT available/resizable
> VG # 0
> MAX LV 256
> Cur LV 1
> Open LV 0
> MAX LV Size 255.99 GB
> Max PV 256
> Cur PV 1
> Act PV 1
> VG Size 111.79 GB
> PE Size 4 MB
> Total PE 28617
> Alloc PE / Size 25600 / 100 GB
> Free PE / Size 3017 / 11.79 GB
> VG UUID rVEO6Y-kq5c-5SR0-uw0I-VPF1-v1ka-HK1WQS
>
> # vgcfgrestore -t -b 1 -l -n data_group /dev/hde
> vgcfgrestore -- INFO: using backup file
> "/etc/lvmconf/data_group.conf.1.old"
> vgcfgrestore -- backup of volume group "data_group" is consistent
> --- Volume group ---
> VG Name data_group
> VG Access read/write
> VG Status NOT available/resizable
> VG # 0
> MAX LV 256
> Cur LV 0
> Open LV 0
> MAX LV Size 255.99 GB
> Max PV 256
> Cur PV 1
> Act PV 1
> VG Size 111.79 GB
> PE Size 4 MB
> Total PE 28617
> Alloc PE / Size 0 / 0
> Free PE / Size 28617 / 111.79 GB
> VG UUID rVEO6Y-kq5c-5SR0-uw0I-VPF1-v1ka-HK1WQS
>
> The first old backup has 0 allocatings, so I don't want this. The most
> recent backup file seems to have an error. If the error is in
> /etc/lvmconf/data_group.conf, how can I recreate the volume group
> descriptor area without touching the data?
> Thanks
>
> PS
> I think I may want to move from a LVM newbee to a LVM tyro (ie.
> understand the descriptor area and metadata data structures -- you
> know at the "a little knowledge is a dangerous thing" level -- about 2
> or 3 levels down from expert :) ). Where's the best place to start to
> learn?
>
> Heinz J . Mauelshagen wrote:
>
>> Duane,
>>
>> does pvscan evetually find more than hde (which I assume should be your
>> _only_ PV in the system) ?
>> If so, you need to decide, if those can be removed (pvcreate -ff ...).
>>
>> If not, you might want to restore the metadata to hde and
>> rescan+activate.
>> (pvcreate -ff /dev/hde;vgcfgrestore -n data_group
>> /dev/hde;vgscan;vgchange -ay).
>>
>> pvcreate doesn't destroy any data, it just initializes the LVM
>> metadata area
>> for vgcfgrestore to work.
>>
>> Regards,
>> Heinz -- The LVM Guy --
>>
>>
>> On Tue, Apr 29, 2003 at 07:36:40PM -0600, Duane Evenson wrote:
>>
>>
>>> I've upgraded to 1.0.7 but now get the following output - indicating
>>> the real problem.
>>> If I recreate the volume group and logical volume, will the data
>>> contained therein still be available or is there another way to
>>> recover the volume?
>>> vgscan -v
>>> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
>>> vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
>>> vgscan -- reading all physical volumes (this may take a while...)
>>> vgscan -- scanning for all active volume group(s) first
>>> vgscan -- reading data of volume group "data_group" from physical
>>> volume(s)
>>> vgscan -- ERROR "vg_read_with_pv_and_lv(): current PV" can't get
>>> data of volume
>>> group "data_group" from physical volume(s)
>>> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
>>> vgscan -- WARNING: This program does not do a VGDA backup of your
>>> volume group
>>>
>>> Some other information of the system:
>>>
>>> # pvdisplay /dev/hde
>>> --- Physical volume ---
>>> PV Name /dev/hde
>>> VG Name data_group
>>> PV Size 111.79 GB [234441648 secs] / NOT usable 4.25
>>> MB [LVM: 239
>>> KB]
>>> PV# 1
>>> PV Status available
>>> Allocatable yes
>>> Cur LV 1
>>> PE Size (KByte) 4096
>>> Total PE 28617
>>> Free PE 3017
>>> Allocated PE 25600
>>> PV UUID x1l2a2-XUzX-XEjZ-hP3k-qAmo-G5jH-U1z1C8
>>>
>>>
>>> # vgcfgrestore -n data_group -ll
>>> vgcfgrestore -- INFO: using backup file "/etc/lvmconf/data_group.conf"
>>> --- Volume group ---
>>> VG Name data_group
>>> VG Access read/write
>>> VG Status NOT available/resizable
>>> VG # 0
>>> MAX LV 256
>>> Cur LV 1
>>> Open LV 0
>>> MAX LV Size 255.99 GB
>>> Max PV 256
>>> Cur PV 1
>>> Act PV 1
>>> VG Size 111.79 GB
>>> PE Size 4 MB
>>> Total PE 28617
>>> Alloc PE / Size 25600 / 100 GB
>>> Free PE / Size 3017 / 11.79 GB
>>> VG UUID rVEO6Y-kq5c-5SR0-uw0I-VPF1-v1ka-HK1WQS
>>>
>>> --- Logical volume ---
>>> LV Name /dev/data_group/logical_volume1
>>> VG Name data_group
>>> LV Write Access read/write
>>> LV Status NOT available
>>> LV # 1
>>> # open 0
>>> LV Size 100 GB
>>> Current LE 25600
>>> Allocated LE 25600
>>> Allocation next free
>>> Read ahead sectors 10000
>>> Block device 58:0
>>>
>>>
>>> --- Physical volume ---
>>> PV Name /dev/hde
>>> VG Name data_group
>>> PV Size 111.79 GB [234441648 secs] / NOT usable 4.25
>>> MB [LVM: 239
>>> KB]
>>> PV# 1
>>> PV Status available
>>> Allocatable yes
>>> Cur LV 1
>>> PE Size (KByte) 4096
>>> Total PE 28617
>>> Free PE 3017
>>> Allocated PE 25600
>>> PV UUID x1l2a2-XUzX-XEjZ-hP3k-qAmo-G5jH-U1z1C8
>>>
>>>
>>> Heinz J . Mauelshagen wrote:
>>>
>>>
>>>
>>>> Duane,
>>>>
>>>> since you're running 1.0.3 I assume you might be hitting an array
>>>> derefenerence
>>>> bug in the LVM1 library we fixed in 1.0.6.
>>>>
>>>> Please upgrade to 1.0.7 and try again.
>>>>
>>>> Regards,
>>>> Heinz -- The LVM Guy --
>>>>
>>>> On Sun, Apr 27, 2003 at 12:22:59PM -0600, Duane Evenson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> I'm having troubles and can't find the solution in the HOWTO, or
>>>>> the archived mailing lists articles.
>>>>> I installed lvm on an entire hard drive (hde), made one logical
>>>>> group with a logical volume of 100G.
>>>>> I mounted to volume, copied files over OK, but vgscan caused
>>>>> segmentation faults.
>>>>> I rebooted, hoping that it was a conflict between the kernel info
>>>>> and physical info. Obviously, it wasn't.
>>>>> Here are the results of running pvdisplay, pvscan, vgscan, and
>>>>> vgdisplay.
>>>>>
>>>>> # pvdisplay /dev/hde -v
>>>>> --- Physical volume ---
>>>>> PV Name /dev/hde
>>>>> VG Name data_group
>>>>> PV Size 111.79 GB [234441648 secs] / NOT usable 4.25
>>>>> MB [LVM: 239
>>>>> KB]
>>>>> PV# 1
>>>>> PV Status available
>>>>> Allocatable yes
>>>>> Cur LV 1
>>>>> PE Size (KByte) 4096
>>>>> Total PE 28617
>>>>> Free PE 3017
>>>>> Allocated PE 25600
>>>>> PV UUID x1l2a2-XUzX-XEjZ-hP3k-qAmo-G5jH-U1z1C8
>>>>>
>>>>> pvdisplay -- "/etc/lvmtab.d/data_group" doesn't exist
>>>>>
>>>>> # pvscan -v
>>>>> pvscan -- reading all physical volumes (this may take a while...)
>>>>> pvscan -- walking through all physical volumes found
>>>>> pvscan -- inactive PV "/dev/hde" is associated to unknown VG
>>>>> "data_group" (run
>>>>> vgscan)
>>>>> pvscan -- total: 1 [111.79 GB] / in use: 1 [111.79 GB] / in no VG:
>>>>> 0 [0]
>>>>>
>>>>> # vgscan -v
>>>>> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
>>>>> vgscan -- creating empty "/etc/lvmtab" and "/etc/lvmtab.d"
>>>>> vgscan -- reading all physical volumes (this may take a while...)
>>>>> vgscan -- scanning for all active volume group(s) first
>>>>> vgscan -- reading data of volume group "data_group" from physical
>>>>> volume(s)
>>>>> Segmentation fault
>>>>>
>>>>> # vgscan -d
>>>>> ...
>>>>> <55555> pv_create_name_from_kdev_t -- LEAVING with dev_name: /dev/hde
>>>>> <55555> system_id_check_exported -- CALLED
>>>>> <55555> system_id_check_exported -- LEAVING with ret: 0
>>>>> <4444> pv_read -- LEAVING with ret: 0
>>>>> <4444> vg_copy_from_disk -- CALLED
>>>>> <55555> vg_check_vg_disk_t_consistency -- CALLED
>>>>> <666666> vg_check_name -- CALLED with VG:
>>>>> <7777777> lvm_check_chars -- CALLED with name: ""
>>>>> <7777777> lvm_check_chars -- LEAVING with ret: 0
>>>>> <666666> vg_check_name -- LEAVING with ret: 0
>>>>> <55555> vg_check_vg_disk_t_consistency -- LEAVING with ret: -344
>>>>> <4444> vg_copy_from_disk -- LEAVING
>>>>> Segmentation fault
>>>>>
>>>>> # vgdisplay data_group -h
>>>>> Logical Volume Manager 1.0.3
>>>>> Heinz Mauelshagen, Sistina Software 19/02/2002 (IOP 10)
>>>>>
>>>>> vgdisplay -- display volume group information
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> linux-lvm mailing list
>>>>> linux-lvm@sistina.com
>>>>> 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
>>>> Mauelshagen@Sistina.com +49 2626 141200
>>>> FAX 924446
>>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-lvm mailing list
>>>> linux-lvm@sistina.com
>>>> http://lists.sistina.com/mailman/listinfo/linux-lvm
>>>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> linux-lvm mailing list
>>> linux-lvm@sistina.com
>>> 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
>> Mauelshagen@Sistina.com +49 2626 141200
>> FAX 924446
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@sistina.com
>> http://lists.sistina.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
>>
>
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-05-02 22:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-04-07 18:31 [linux-lvm] Vgscan problem Patrick Boutilier
2000-04-07 21:57 ` Heinz Mauelshagen
2000-04-08 11:09 ` Patrick Boutilier
-- strict thread matches above, loose matches on Subject: below --
2002-01-06 19:29 [linux-lvm] vgscan problem Andrew Schaefer
2002-01-15 8:30 ` Heinz J . Mauelshagen
2003-04-27 13:17 [linux-lvm] vgscan segmentation faults, VG name problems Duane Evenson
2003-04-28 4:03 ` Heinz J . Mauelshagen
2003-04-29 20:34 ` [linux-lvm] vgscan problem (was vgscan segmentation faults, VG name problems) Duane Evenson
2003-04-30 6:11 ` Heinz J . Mauelshagen
2003-04-30 21:12 ` Duane Evenson
2003-05-02 22:29 ` [linux-lvm] vgscan problem Duane Evenson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.