[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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) (Leigh Waldie)



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 mih-assoc com>
> To: <linux-lvm 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 sistina com
> 
> Thanks for the reply...
> 
> -----Original Message-----
> From: linux-lvm-admin sistina com [mailto:linux-lvm-admin sistina com]On
> Behalf Of linux-lvm-request sistina com
> Sent: 04 July 2002 10:49
> >Message: 7
> >Date: Thu, 4 Jul 2002 11:34:54 +0200
> >From: "Heinz J . Mauelshagen" <mauelshagen sistina com>
> >To: linux-lvm 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 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 sistina com>
> To: linux-lvm 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 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 sistina com [mailto:linux-lvm-admin sistina com]On
> > Behalf Of linux-lvm-request sistina com
> > Sent: 04 July 2002 10:49
> > >Message: 7
> > >Date: Thu, 4 Jul 2002 11:34:54 +0200
> > >From: "Heinz J . Mauelshagen" <mauelshagen sistina com>
> > >To: linux-lvm 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 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 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 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 snifter freeserve co uk>
> To: linux-lvm sistina com
> Date: 04 Jul 2002 16:02:12 +0100
> Reply-To: linux-lvm 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 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 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
> >
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-
> >
> > _______________________________________________
> > 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
> >
> 
> 
> 
> 
> --__--__--
> 
> Message: 4
> From: "James B. Byrne " <ByrneJB Harte-Lyne ca>
> Organization: Harte & Lyne Limited
> To: linux-lvm 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 sistina com
> 
> On 4 Jul 2002 at 4:49, "Heinz J . Mauelshagen"
> <mauelshagen 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 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 hotmail com>
> To: linux-kernel vger kernel org
> Cc: joe fib011235813 fsnet co uk, linux-lvm 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 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 sistina com>
> To: linux-lvm sistina com
> Subject: Re: [linux-lvm] Re: linux-lvm digest, Vol 1 #624 - 8 msgs
> Reply-To: linux-lvm 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 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 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 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 Sistina com                           +49 2626 141200
>                                                        FAX 924446
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-
> 
> 
> --__--__--
> 
> Message: 7
> From: Benjamin Herrenschmidt <benh kernel crashing org>
> To: <linux-LVM 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 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 kernel crashing org>
> =C0: linux-kernel 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 glorybox de>
> To: linux-lvm sistina com
> Subject: [linux-lvm] Get rid of files of a non existing volume group
> Reply-To: linux-lvm 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 sistina com>
> To: linux-lvm sistina com
> Subject: Re: [linux-lvm] Get rid of files of a non existing volume group
> Reply-To: linux-lvm 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 glorybox de>
> To: linux-lvm sistina com
> Subject: Re: [linux-lvm] Get rid of files of a non existing volume group
> Reply-To: linux-lvm sistina com
> 
> + Patrick Caulfield <caulfield 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 conectiva com br>
> To:	linux-lvm sistina com
> Subject: [linux-lvm] lvm & 2.5
> Reply-To: linux-lvm 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 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 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 Sistina com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]