[linux-lvm] Re: RE: ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume group "data_disks" from physical volume(s) (Heinz J . Mauelshagen) (Leigh Waldie)
Andres Salomon
dilinger at mp3revolution.net
Mon Jul 8 10:54:01 UTC 2002
Yep.
[dilinger at incandescent dilinger]$ lspci |grep -i promise
00:0a.0 Unknown mass storage controller: Promise Technology, Inc.:
Unknown device 4d69 (rev 02)
[dilinger at incandescent dilinger]$ sudo pvscan
Password:
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE PV "/dev/ide/host2/bus1/target0/lun0/part1" of VG
"site" [152.64 GB / 0 free]
pvscan -- ACTIVE PV "/dev/ide/host2/bus0/target0/lun0/part1" of VG
"site" [152.64 GB / 0 free]
pvscan -- total: 2 [305.33 GB] / in use: 2 [305.33 GB] / in no VG: 0 [0]
Works fine for me..
On Mon, Jul 08, 2002 at 11:00:49AM +0200, Heinz J . Mauelshagen wrote:
>
> On Mon, Jul 08, 2002 at 09:28:45AM +0100, Leigh Waldie wrote:
> > Heinz,
> >
> > Thanks for your input on this, but I have now gone back to standard linux
> > partitions on these disks and everything works fine. I am assuming that
> > there are compatibility issues with using LVM on a 160GB disk on a promise
> > ATA133 TX2 controller and I am going to give up on LVM for now.
>
> Leigh,
>
> I don't believe that this is the reason.
>
> Maybe someone else on this list has experience with this HW under LVM?
>
> Regards,
> Heinz -- The LVM Guy --
>
> > I would love
> > to be able to use it, as it seems to be extremely useful, but given the
> > teething problems i have had, I cant really rely on it.
> >
> > I hope to be able to try again at a later date, maybe things will have
> > changed by then.
> >
> > Thanks again for your time...
> >
> > Leigh Waldie
> >
> >
> > ---------------------------------------
> > From: "Leigh Waldie" <lw at mih-assoc.com>
> > To: <linux-lvm at sistina.com>
> > Date: Thu, 4 Jul 2002 13:22:45 +0100
> > Subject: [linux-lvm] Re: RE: ERROR "vg_read_with_pv_and_lv(): current PV"
> > can't get data of volume group "data_disks" from physical volume(s) (Heinz J
> > . Mauelshagen)
> > Reply-To: linux-lvm at sistina.com
> >
> > Thanks for the reply...
> >
> > -----Original Message-----
> > From: linux-lvm-admin at sistina.com [mailto:linux-lvm-admin at sistina.com]On
> > Behalf Of linux-lvm-request at sistina.com
> > Sent: 04 July 2002 10:49
> > >Message: 7
> > >Date: Thu, 4 Jul 2002 11:34:54 +0200
> > >From: "Heinz J . Mauelshagen" <mauelshagen at sistina.com>
> > >To: linux-lvm at sistina.com
> > >Subject: Re: [linux-lvm] RE: ERROR "vg_read_with_pv_and_lv(): current PV"
> > can't get data of volume group "data_disks" from physical volume(s)
> > >Reply-To: linux-lvm at sistina.com
> >
> > >On Wed, Jul 03, 2002 at 02:25:20PM +0100, Leigh Waldie wrote:
> > >> Further...
> > >>
> > >> Output from pvdata /dev/hde reveals that there is no vg info on the disk,
> > >> however there is vg info on the second disk /dev/hdb...
> >
> > >Then the vgcfgrestore must have been unsuccessfull :(
> >
> > indeed it was
> >
> > >"vgchange -an" is not needed. It doesn't write to the PVs it just tries
> > >to deactivate the VGs in core.
> >
> > >>
> > >> Is there any way of recovering the vg info from hdb onto hde ?
> >
> > >vgcfgrestore!
> >
> > >Look with "vgcfgrestore -ll ..." if your backup fits your config,
> >
> > the output from vgcfgrestore -ll -n data_disks -f
> > /etc/lvmconf/data_disks.conf looked good to me.
> > It listed the volume group , the logical volume and the two PVs and all the
> > sizes seem correct.
> > So i went ahead to the next step...
> >
> > >run
> >
> > > pvcreate -ff /dev/hde
> >
> > worked ok - said it was successful
> >
> > >and
> >
> > > vgcfgrestore -n data_disks -f /etc/lvmconf/YourPreferedArchive /dev/hde
> >
> > when i run
> > vgcfgrestore -n data_disks -f /etc/lvmconf/data_disks.conf /dev/hde
> >
> > it reports that VG for data_disks successfully restored to /dev/hde
> > but it also says : you may not have an actual backup of restored volume
> > group "data_disks"
> >
> > and when i try vgscan i get the same error as in the subject line
> > above...( pvdata /dev/hde still shows no volume group on the PV )
> >
> > I have several other cfg backups which I have also tried, all of which give
> > me the same result.
> >
> > I'm pretty much coming to the conclusion that something else is happening
> > here but I dont know what...
> > I suspect that the disk controller may be screwing up.
> >
> > I got fed up with trying all the correct tools as they were obviously having
> > a problem with this disk so i used dd to back up the first 512k of the
> > /dev/hde disk and the used dd again to "copy" the first 512k of data from
> > disk /dev/hdb to /dev/hde just to test whether or not pvdata would then like
> > the disk ( I know I couldn't use the disk in this state, just trying it out
> > of interest ).
> >
> > The results are very strange.
> >
> > If I use "dd if=/dev/hde |xxd |more" I can see that the VG UUID is at hex
> > 0x0001200 for 32 bytes, but if I use "xxd /dev/hde |more" I can see the VG
> > uuid at hex 0x0001000 for 32 bytes, which is where I presume it is meant to
> > be judging by the data on the other disks.
> >
> > This is leading me to suspect a hardware problem, so I think I will try
> > moving the disk onto another controller and see how that goes..
> >
> >
> > >and
> >
> > > vgscan ; vgchange -ay
> >
> >
> > >That should do the trick.
> >
> >
> > >The open question is, what overwrote your LVM metadata (and hopefully just
> > >it) on /dev/hde in the first place.
> >
> > >Regards,
> > >Heinz -- The LVM Guy --
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.372 / Virus Database: 207 - Release Date: 20/06/2002
> >
> >
> >
> > --__--__--
> >
> > Message: 2
> > Date: Thu, 4 Jul 2002 14:34:51 +0200
> > From: "Heinz J . Mauelshagen" <mauelshagen at sistina.com>
> > To: linux-lvm at sistina.com
> > Subject: Re: [linux-lvm] Re: RE: ERROR "vg_read_with_pv_and_lv(): current
> > PV" can't get data of volume group "data_disks" from physical volume(s)
> > (Heinz J . Mauelshagen)
> > Reply-To: linux-lvm at sistina.com
> >
> >
> > Leigh,
> >
> > that pvdata still can't see the VGDA after your successfull vgcfgrestore
> > indeed points to a hardware flaw.
> >
> > You should find the VG UUID at offset 0x400 on the disk with metadata
> > created by LVM versions before 0.9.1 Beta 8.
> >
> > With newer LVM versions it sits at offset 0x1000 as you suggested
> > (LVM_VGDA_ALIGN definition in tools/lib/liblvm.h).
> >
> > Please get back once you sorted out any HW problems.
> >
> > Regards,
> > Heinz -- The LVM Guy --
> >
> >
> >
> > On Thu, Jul 04, 2002 at 01:22:45PM +0100, Leigh Waldie wrote:
> > > Thanks for the reply...
> > >
> > > -----Original Message-----
> > > From: linux-lvm-admin at sistina.com [mailto:linux-lvm-admin at sistina.com]On
> > > Behalf Of linux-lvm-request at sistina.com
> > > Sent: 04 July 2002 10:49
> > > >Message: 7
> > > >Date: Thu, 4 Jul 2002 11:34:54 +0200
> > > >From: "Heinz J . Mauelshagen" <mauelshagen at sistina.com>
> > > >To: linux-lvm at sistina.com
> > > >Subject: Re: [linux-lvm] RE: ERROR "vg_read_with_pv_and_lv(): current PV"
> > > can't get data of volume group "data_disks" from physical volume(s)
> > > >Reply-To: linux-lvm at sistina.com
> > >
> > > >On Wed, Jul 03, 2002 at 02:25:20PM +0100, Leigh Waldie wrote:
> > > >> Further...
> > > >>
> > > >> Output from pvdata /dev/hde reveals that there is no vg info on the
> > disk,
> > > >> however there is vg info on the second disk /dev/hdb...
> > >
> > > >Then the vgcfgrestore must have been unsuccessfull :(
> > >
> > > indeed it was
> > >
> > > >"vgchange -an" is not needed. It doesn't write to the PVs it just tries
> > > >to deactivate the VGs in core.
> > >
> > > >>
> > > >> Is there any way of recovering the vg info from hdb onto hde ?
> > >
> > > >vgcfgrestore!
> > >
> > > >Look with "vgcfgrestore -ll ..." if your backup fits your config,
> > >
> > > the output from vgcfgrestore -ll -n data_disks -f
> > > /etc/lvmconf/data_disks.conf looked good to me.
> > > It listed the volume group , the logical volume and the two PVs and all
> > the
> > > sizes seem correct.
> > > So i went ahead to the next step...
> > >
> > > >run
> > >
> > > > pvcreate -ff /dev/hde
> > >
> > > worked ok - said it was successful
> > >
> > > >and
> > >
> > > > vgcfgrestore -n data_disks -f /etc/lvmconf/YourPreferedArchive /dev/hde
> > >
> > > when i run
> > > vgcfgrestore -n data_disks -f /etc/lvmconf/data_disks.conf /dev/hde
> > >
> > > it reports that VG for data_disks successfully restored to /dev/hde
> > > but it also says : you may not have an actual backup of restored volume
> > > group "data_disks"
> > >
> > > and when i try vgscan i get the same error as in the subject line
> > > above...( pvdata /dev/hde still shows no volume group on the PV )
> > >
> > > I have several other cfg backups which I have also tried, all of which
> > give
> > > me the same result.
> > >
> > > I'm pretty much coming to the conclusion that something else is happening
> > > here but I dont know what...
> > > I suspect that the disk controller may be screwing up.
> > >
> > > I got fed up with trying all the correct tools as they were obviously
> > having
> > > a problem with this disk so i used dd to back up the first 512k of the
> > > /dev/hde disk and the used dd again to "copy" the first 512k of data from
> > > disk /dev/hdb to /dev/hde just to test whether or not pvdata would then
> > like
> > > the disk ( I know I couldn't use the disk in this state, just trying it
> > out
> > > of interest ).
> > >
> > > The results are very strange.
> > >
> > > If I use "dd if=/dev/hde |xxd |more" I can see that the VG UUID is at hex
> > > 0x0001200 for 32 bytes, but if I use "xxd /dev/hde |more" I can see the VG
> > > uuid at hex 0x0001000 for 32 bytes, which is where I presume it is meant
> > to
> > > be judging by the data on the other disks.
> > >
> > > This is leading me to suspect a hardware problem, so I think I will try
> > > moving the disk onto another controller and see how that goes..
> > >
> > >
> > > >and
> > >
> > > > vgscan ; vgchange -ay
> > >
> > >
> > > >That should do the trick.
> > >
> > >
> > > >The open question is, what overwrote your LVM metadata (and hopefully
> > just
> > > >it) on /dev/hde in the first place.
> > >
> > > >Regards,
> > > >Heinz -- The LVM Guy --
> > >
> > >
> > >
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.372 / Virus Database: 207 - Release Date: 20/06/2002
> > >
> > >
> > > _______________________________________________
> > > linux-lvm mailing list
> > > linux-lvm at sistina.com
> > > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> >
> > *** 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 at Sistina.com +49 2626 141200
> > FAX 924446
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > =-
> >
> >
> > --__--__--
> >
> > Message: 3
> > Subject: Re: [linux-lvm] ERROR "vg_read_with_pv_and_lv(): current PV" can't
> > get data of volume group
> > From: Eamonn Hamilton <eamonn at snifter.freeserve.co.uk>
> > To: linux-lvm at sistina.com
> > Date: 04 Jul 2002 16:02:12 +0100
> > Reply-To: linux-lvm at sistina.com
> >
> > no problem, files are on the way :-)
> >
> >
> > On Thu, 2002-07-04 at 10:20, Heinz J . Mauelshagen wrote:
> > >
> > > Eamonn,
> > >
> > > could you send the output to me directly (mge at sistina.com), please?
> > >
> > > On Tue, Jul 02, 2002 at 12:55:43PM +0100, Eamonn Hamilton wrote:
> > > >
> > > >
> > > > Hi.
> > > >
> > > > I'm getting the error as shown in the subject line from a system which
> > > > was shut down improperly ( read: turned off ! ). Is there anything I can
> > > > do to recover this, as the disks all seem fine, and pvscan finds the
> > > > physical volumes.
> > > >
> > > > Any pointers gratefully received ..
> > > >
> > > > Cheers,
> > > > Eamonn
> > > >
> > > > P.S
> > > >
> > > > pvscan -d and vgscan -d on request, as I don't want to throw 70k at the
> > > > list :-)
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > linux-lvm mailing list
> > > > linux-lvm at 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 at Sistina.com +49 2626 141200
> > > FAX 924446
> > >
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > =-
> > >
> > > _______________________________________________
> > > linux-lvm mailing list
> > > linux-lvm at sistina.com
> > > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> > >
> >
> >
> >
> >
> > --__--__--
> >
> > Message: 4
> > From: "James B. Byrne " <ByrneJB at Harte-Lyne.ca>
> > Organization: Harte & Lyne Limited
> > To: linux-lvm at sistina.com
> > Date: Thu, 4 Jul 2002 11:11:49 -0400
> > Subject: [linux-lvm] Re: linux-lvm digest, Vol 1 #624 - 8 msgs
> > Reply-To: linux-lvm at sistina.com
> >
> > On 4 Jul 2002 at 4:49, "Heinz J . Mauelshagen"
> > <mauelshagen at sistina.com> wrote:
> >
> > > Did you just grow the LV?
> > >
> >
> > Yes
> >
> > > You need to extend the FS using the respective FS resizing tool as
> > > well (resize2fs, resize_reiserfs, ...).
> > >
> >
> > Did that too.
> >
> > > BTW: for ext2 the e2fsadm(8) command, which comes with LVM does both
> > > for you.
> > >
> > >
> >
> > I tried this originally but I can't remember if it worked first off or if in
> > my ignorance I ran it out of sequence, had problems, and ended up
> > doing something else. In any case eventually I managed to get the
> > file system up to 350 Mb.
> >
> > > This doesn't really explain the local/remote difference unless:
> > >
> > > - local users had root credentials avoiding the fs
> > > "reserved block count" to matter
> >
> > As it turned out the local user did have root capability but when su to
> > a non-privileged user the local file transfers also worked.
> > >
> > > - files uploaded where very large compared to the locally stored files
> >
> > The reverse in fact, the local files moved in for testing averaged 10x
> > the size of normal ftp uploads. However, the culprit was discovered
> > and it wasn't lvm. The problem appears to have been a simple
> > permission problem in the directory tree for the ftp chroot. Why
> > pureftpd chose to report this as a disk full error is beyond me.
> >
> > However, it is worth noting that rebooting the system, without
> > making any other changes, caused pureftp to subsequently report a
> > different error message for the same activity. The message didn't
> > actually say access forbidden ( I think that it was more like "non
> > existent file", but with the application of a little intuition it did point
> > to
> > a permissions problem.
> >
> > Regards,
> > Jim
> >
> >
> > --- e-mail is NOT a secure channel
> > James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
> > Harte & Lyne Limited http://www.harte-lyne.ca
> > 9 Brockley Drive vox: +1 905 561 1241
> > Hamilton, Ontario fax: +1 905 561 0757
> > Canada L8E 3C3
> >
> >
> >
> > --__--__--
> >
> > Message: 5
> > From: "Mark Peloquin" <markpeloquin at hotmail.com>
> > To: linux-kernel at vger.kernel.org
> > Cc: joe at fib011235813.fsnet.co.uk, linux-lvm at sistina.com
> > Subject: Re: [linux-lvm] LVM2 modifies the buffer_head struct?
> > Date: Fri, 05 Jul 2002 00:21:56 -0500
> > Reply-To: linux-lvm at sistina.com
> >
> > On 2002-07-02 14:17:02, Joe wrote:
> >
> > >This is a horrible hack to get around the fact that ext3 uses the
> > >b_private field for its own purposes after the buffer_head has been
> > >handed to the block layer (it doesn't just use b_private when in the
> > >b_end_io function). Is this acceptable behaviour ? Other > filesystems
> > >do not have similar problems as far as I know.
> >
> > Under what conditions does ext3 exhibit this behaviour? In EVMS, we have
> > been stacking the b_private field (for many months), and have not seen any
> > problems or have had any problems reported with ext3.
> >
> > Mark
> >
> >
> >
> > _________________________________________________________________
> > Join the world’s largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com
> >
> >
> >
> > --__--__--
> >
> > Message: 6
> > Date: Fri, 5 Jul 2002 11:54:22 +0200
> > From: "Heinz J . Mauelshagen" <mauelshagen at sistina.com>
> > To: linux-lvm at sistina.com
> > Subject: Re: [linux-lvm] Re: linux-lvm digest, Vol 1 #624 - 8 msgs
> > Reply-To: linux-lvm at sistina.com
> >
> >
> > James,
> >
> > good to hear that it works for you now.
> >
> > Cheers,
> > Heinz -- The LVM Guy --
> >
> > On Thu, Jul 04, 2002 at 11:11:49AM -0400, James B. Byrne wrote:
> > > On 4 Jul 2002 at 4:49, "Heinz J . Mauelshagen"
> > > <mauelshagen at sistina.com> wrote:
> > >
> > > > Did you just grow the LV?
> > > >
> > >
> > > Yes
> > >
> > > > You need to extend the FS using the respective FS resizing tool as
> > > > well (resize2fs, resize_reiserfs, ...).
> > > >
> > >
> > > Did that too.
> > >
> > > > BTW: for ext2 the e2fsadm(8) command, which comes with LVM does both
> > > > for you.
> > > >
> > > >
> > >
> > > I tried this originally but I can't remember if it worked first off or if
> > in
> > > my ignorance I ran it out of sequence, had problems, and ended up
> > > doing something else. In any case eventually I managed to get the
> > > file system up to 350 Mb.
> > >
> > > > This doesn't really explain the local/remote difference unless:
> > > >
> > > > - local users had root credentials avoiding the fs
> > > > "reserved block count" to matter
> > >
> > > As it turned out the local user did have root capability but when su to
> > > a non-privileged user the local file transfers also worked.
> > > >
> > > > - files uploaded where very large compared to the locally stored files
> > >
> > > The reverse in fact, the local files moved in for testing averaged 10x
> > > the size of normal ftp uploads. However, the culprit was discovered
> > > and it wasn't lvm. The problem appears to have been a simple
> > > permission problem in the directory tree for the ftp chroot. Why
> > > pureftpd chose to report this as a disk full error is beyond me.
> > >
> > > However, it is worth noting that rebooting the system, without
> > > making any other changes, caused pureftp to subsequently report a
> > > different error message for the same activity. The message didn't
> > > actually say access forbidden ( I think that it was more like "non
> > > existent file", but with the application of a little intuition it did
> > point to
> > > a permissions problem.
> > >
> > > Regards,
> > > Jim
> > >
> > >
> > > --- e-mail is NOT a secure channel
> > > James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
> > > Harte & Lyne Limited http://www.harte-lyne.ca
> > > 9 Brockley Drive vox: +1 905 561 1241
> > > Hamilton, Ontario fax: +1 905 561 0757
> > > Canada L8E 3C3
> > >
> > >
> > > _______________________________________________
> > > linux-lvm mailing list
> > > linux-lvm at sistina.com
> > > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> >
> > *** 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 at Sistina.com +49 2626 141200
> > FAX 924446
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > =-
> >
> >
> > --__--__--
> >
> > Message: 7
> > From: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> > To: <linux-LVM at sistina.com>
> > Date: Fri, 5 Jul 2002 12:28:09 +0200
> > Subject: [linux-lvm] Tr: Possible LVM bug in 2.4.19-rc1
> > Reply-To: linux-lvm at sistina.com
> >
> > ---------------- D=E9but du message transmis ----------------
> > Sujet: Possible LVM bug in 2.4.19-rc1
> > Envoy=E9: jeudi 4 juillet 2002 13:59
> > De: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> > =C0: linux-kernel at vger.kernel.org
> >
> > Hi !
> >
> > Olaf and I have been tracking down a bug where the kernel died
> > into lvm=5Fblk=5Fopen() during boot on pmac, and later on other PPCs
> > when trying to access an unconfigured LVM block device (or an
> > LVM minor not associated yet). This typically happened in the
> > pmac root discovery code which walks all gendisks, but I beleive
> > there are other possible exploits.
> >
> > Here's what I've tracked down so far:
> >
> > static int lvm=5Fblk=5Fopen(struct inode *inode, struct file *file)
> > {
> > =09int minor =3D MINOR(inode->i=5Frdev);
> > =09lv=5Ft *lv=5Fptr;
> > =09vg=5Ft *vg=5Fptr =3D vg[VG=5FBLK(minor)];
> >
> > =09P=5FDEV("blk=5Fopen MINOR: %d VG#: %d LV#: %d mode: %s%s\n",
> > =09 minor, VG=5FBLK(minor), LV=5FBLK(minor),
> > =09 MODE=5FTO=5FSTR(file->f=5Fmode));
> >
> > #ifdef LVM=5FTOTAL=5FRESET
> > =09 if (lvm=5Freset=5Fspindown > 0)
> > =09 =09return -EPERM;
> > #endif
> >
> > =09if (vg=5Fptr !=3D NULL &&
> > =09 (vg=5Fptr->vg=5Fstatus & VG=5FACTIVE) &&
> >
> > .../...
> >
> > At this point, no association have been made. That is VG=5FBLK(minor)
> > will return vg=5Flv=5Fmap[minor].vg=5Fnumber which has been initialized
> > to ABS=5FMAX=5FVG in lvm=5Finit=5Fvars().
> >
> > That means that vg=5Fptr is set to vg[ABS=5FMAX=5FVG], which is right =
> > outside
> > the array bounds, as vg is declared to be
> >
> > /* volume group descriptor area pointers */
> > vg=5Ft *vg[ABS=5FMAX=5FVG];
> >
> > So, as soon as we dereference vg=5Fptr, we get whatever garbage is located
> > right after the array, and not the NULL value we would expect for a non
> > initialized association.
> >
> > If my understanding is correct, then a simple fix would be to
> >
> > /* volume group descriptor area pointers */
> > - vg=5Ft *vg[ABS=5FMAX=5FVG];
> > + vg=5Ft *vg[ABS=5FMAX=5FVG+1];
> >
> > though it's a bit hackish... maybe we should just test
> > VG=5FBLK < ABS=5FMAX=5FVG
> >
> > Also, the loop initializing vg array to NULL can probably be removed
> > from lvm=5Finit=5Fvars as vg is part of the BSS and thus cleared by default.
> >
> > Did I miss something =3F
> >
> > Ben.
> >
> > ----------------- Fin du message transmis -----------------
> >
> >
> >
> >
> > --__--__--
> >
> > Message: 8
> > Date: Fri, 5 Jul 2002 22:53:24 +0200
> > From: Kai Weber <lists at glorybox.de>
> > To: linux-lvm at sistina.com
> > Subject: [linux-lvm] Get rid of files of a non existing volume group
> > Reply-To: linux-lvm at sistina.com
> >
> > Hi,
> >
> > I have lost a hard disk (died). I had a volume group on this disk. Now I
> > have replaced the disk with a new one and wanted to create the old scheme
> > on this disk:
> >
> > $ vgcreate datavg /dev/hdb1
> > vgcreate -- directory /dev/datavg already exists
> >
> > As you can see the old /dev/datavg still exists on my root-partition. How
> > do I get rid of the old files? There is no VG datavg anymore, but I want to
> > have the name back.
> >
> > Can I 'rm -rf /dev/datavg' the files? Or should I do a vgextend?
> >
> > vgscan does not find the VG datavg anymore.
> >
> > Kai
> >
> >
> > --__--__--
> >
> > Message: 9
> > Date: Sat, 6 Jul 2002 09:27:58 +0100
> > From: Patrick Caulfield <caulfield at sistina.com>
> > To: linux-lvm at sistina.com
> > Subject: Re: [linux-lvm] Get rid of files of a non existing volume group
> > Reply-To: linux-lvm at sistina.com
> >
> > On Fri, Jul 05, 2002 at 10:53:24PM +0200, Kai Weber wrote:
> > > Hi,
> > >
> > > I have lost a hard disk (died). I had a volume group on this disk. Now I
> > > have replaced the disk with a new one and wanted to create the old scheme
> > > on this disk:
> > >
> > > $ vgcreate datavg /dev/hdb1
> > > vgcreate -- directory /dev/datavg already exists
> > >
> > > As you can see the old /dev/datavg still exists on my root-partition. How
> > > do I get rid of the old files? There is no VG datavg anymore, but I want
> > to
> > > have the name back.
> > >
> > > Can I 'rm -rf /dev/datavg' the files? Or should I do a vgextend?
> >
> > You can safely delete the directory. When you re-created the VG and LVs then
> > nodes will be re-created.
> >
> > > vgscan does not find the VG datavg anymore.
> >
> > Well...er... if it's a totally new disk it won't. :)
> >
> > patrick
> >
> >
> >
> > --__--__--
> >
> > Message: 10
> > Date: Sat, 6 Jul 2002 15:00:52 +0200
> > From: Kai Weber <lists at glorybox.de>
> > To: linux-lvm at sistina.com
> > Subject: Re: [linux-lvm] Get rid of files of a non existing volume group
> > Reply-To: linux-lvm at sistina.com
> >
> > + Patrick Caulfield <caulfield at sistina.com>:
> >
> > > > Can I 'rm -rf /dev/datavg' the files? Or should I do a vgextend?
> > >
> > > You can safely delete the directory. When you re-created the VG and
> > > LVs then nodes will be re-created.
> >
> > It worked. I ever thought the dev-files for LVM are created dynamicly.
> > So I feared removing the files would not be succesfull. And I am not a
> > friend of experiments... *g*
> >
> > Thank you
> > Kai
> >
> >
> > --__--__--
> >
> > Message: 11
> > Date: Sat, 6 Jul 2002 13:39:39 -0300 (BRT)
> > From: Rik van Riel <riel at conectiva.com.br>
> > To: linux-lvm at sistina.com
> > Subject: [linux-lvm] lvm & 2.5
> > Reply-To: linux-lvm at sistina.com
> >
> > Hi,
> >
> > are there any plans to fix lvm support for 2.5 or should I
> > drop lvm from my test boxes until 2.6 comes out ?
> >
> > Rik
> > --
> > Bravely reimplemented by the knights who say "NIH".
> >
> > http://www.surriel.com/ http://distro.conectiva.com/
> >
> >
> >
> >
> > --__--__--
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm at sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> >
> >
> > End of linux-lvm Digest
> >
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/2002
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/2002
> >
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm at sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
> *** 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 at Sistina.com +49 2626 141200
> FAX 924446
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
Broad surveillance is a mark of bad security.
-- Bruce Schneier
More information about the linux-lvm
mailing list