Bug 28063 - pvcreate incorrectly detects size of software RAID volume
pvcreate incorrectly detects size of software RAID volume
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: lvm (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-16 18:53 EST by Tim Clymo
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-25 15:28:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Clymo 2001-02-16 18:53:15 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.0-0.99.11 i686)


I have a  RAID 1 device (/dev/md1) consisting of 2 x 8422.69Mb extended
partitions (as reported by cfdisk) - /dev/hdg5 and /dev/hde7.
The immediately preceding partitions on hdg and hde (#'s 1 and 6
respectively) are set up as a 24.68Mb RAID 1 device for /boot - /dev/md0
When I do a pvcreate on /dev/md1 and then a pvdisplay, it is reported as a
PV of size 23.44Mb

This is a vanilla install from fisher ISO's - no components have been
changed from the original RH distribution

Reproducible: Always
Steps to Reproduce:
1. On each of 2 x EIDE disks, create primary partition #1 @ c.20Mb (type
fd)
2. Repeat step 1 to create extended partition @ c.8Gb on each disk
3. Set up each pair of partitions as RAID 1 (md0 for the 20Mb and md1 for
the 8Gb)
4. pvcreate /dev/md1
5. pvdisplay /dev/md1
	

Actual Results:  /dev/md1 reported as 23Mb

Expected Results:  should have been 8Gb

I'm not sure where the incorrect size is coming from, but it seems
coincidental that it is actually about the same as the real size of the
immediately preceding entries in the partition table.

If I turn off the RAID and change the partiton type to 8e, pvcreate on
/dev/hdeX and /dev/hdgX behaves as expected (although now on a single
device instead of a RAID pair)
Comment 1 Glen Foster 2001-02-17 18:31:53 EST
We (Red Hat) should really try to resolve this before next release.
Comment 2 Florian La Roche 2001-02-22 09:52:26 EST
Can you please check out http://people.redhat.com/laroche/? I have uploaded the
newest (beta) source packaged as rpm. If that fixes the problem, I'd know that
this
bug is already fixed upstream.

Thanks for this bug-report.

Comment 3 Tim Clymo 2001-02-24 16:51:52 EST
The beta5 RPM fails a dependency on liblvm-11.so.0, so I can't install it

However, I did build beta4 from the tar source at Sistina, and the pvcreate
problem seems to have been fixed. The only trouble was that I built a new kernel
incorporating the patches in Sistina's LVM distribution along with the beta4,
and it broke XFree86 (X just crashed on startup).

Replacing the kernel with Fisher's original made X work again, but I wasn't
comfortable with the new beta4 LVM (I don't have any idea what the kernel
patches were for, but they may have been important!) - so I reinstalled the
0.9-1 RPM.
Comment 4 Tim Clymo 2001-02-25 08:55:03 EST
OK, now I built the beta5 LVM from the source RPM (loads of warnings "lvm_log.h
nothing can be pasted after this token"). I copied
/usr/src/redhat/BUILD/LVM/0.9.1_beta5/tools/lib/liblvm-11* into /lib and
installed the RPM file with --nodeps (I guess this is an RPM issue - the target
package really ought to include the liblvm-11* stuff).

Now, when I run vgscan, it says "invalid i/o protocol version 10".

I suspect this must be due to the fact that it's not enough simply to install
the LVM tools - the kernel needs to have some patches applied. The source
documentation certainly suggests as much.

I'm actually running the 2.4.1 kernel from Wolverine now, which I think contains
the 0.9.1_beta2 patches (at least it says so in dmesg). Perhaps Redhat could
consider producing a 2.4.1 kernel with the LVM beta5 patches and test that it
doesn't interfere with X
Comment 5 Tim Clymo 2001-02-25 15:28:54 EST
Right - now it works. Here is what I did:
1) Install Wolverine kernel-source RPM
2) Download LVM beta5 source RPM, and do an rpm -i on it
3) Edit /usr/src/redhat/SPECS/lvm.spec, append
"--with-kernel_dir=/usr/src/linux-2.4" to configure command on line 28
4) rpm -ba /usr/src/redhat/SPECS/lvm.spec
5) cd to /usr/src/redhat/BUILD/LVM/0.9.1_beta5/PATCHES
6) Edit Makefile and change KERNEL_VERSION on line 28 to "2.4.1-0.1.9"
7) make (to create patch file)
8) cd /usr/src/linux-2.4
9) make mrproper
10) edit Makefile, change EXTRAVERSION from -0.1.9 to -0.1.10 on line 4
11) copy configs/kernel-2.4.1-i686.config to arch/i386/defconfig
12) patch -p1 <
/usr/src/redhat/BUILD/LVM/0.9.1_beta5/PATCHES/lvm-0.9.1_beta5-2.4.1-0.1.9.patch
13) make menuconfig and save configuration (make xconfig doesn't work - I put
another bugzilla report in for this)
14) make dep, make bzImage make modules, make modules_install
15) copy new kernel and related stuff into /boot, create new initrd image, edit
lilo.conf and do a lilo -v
16) reboot new kernel and install LVM from RPM created in step 4) (with --nodeps
to ignore the dependancy failure on liblvm-11.so.0)
17) copy /usr/src/redhat/BUILD/LVM/0.9.1_beta5/tools/lib/liblvm-11* to /lib
18) reboot just to be sure - OK, now it works, and X seems happy too.

I have no idea exactly how much of this was strictly necessary, but it's what I
did and it seems to work
Comment 6 Matt Wilson 2001-03-16 18:04:06 EST
lvm will be disabled for the next release.  This bug will be deferred until lvm
is supported in Red Hat Linux.

Note You need to log in before you can comment on or make changes to this bug.