[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)
Leigh Waldie
lw at mih-assoc.com
Mon Jul 8 03:28:02 UTC 2002
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. 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
More information about the linux-lvm
mailing list