[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)
Heinz J . Mauelshagen
mauelshagen at sistina.com
Mon Jul 8 04:09:01 UTC 2002
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
More information about the linux-lvm
mailing list