Yep. [dilinger@incandescent dilinger]$ lspci |grep -i promise 00:0a.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 4d69 (rev 02) [dilinger@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@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 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > _______________________________________________ > 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 -- Broad surveillance is a mark of bad security. -- Bruce Schneier _______________________________________________ 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
