Bug 122115 - Anaconda crashes when asked to create volgroup for 2 disc span in kickstart
Anaconda crashes when asked to create volgroup for 2 disc span in kickstart
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Alasdair Kergon
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-30 13:02 EDT by Howard Wilkinson
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-31 09:58:50 EDT
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 Howard Wilkinson 2004-04-30 13:02:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)

Description of problem:
I have been struggling with kickstart on test3 release and have found
a number of problems which I will post patches for. But I have run up
against one I can't immediately diagnose and need to report while the
problem is fresh.

I have a kickstart build onto a system with 2 discs. If I create a
raid0 for the root partition. I can then use LVM to create a span over
the remaining areas of the discs and allocate my other paritions out
of this. If I try to create the LVM span and allocate root in this
then anaconda fails trying to create the PV. I am not sure which PV is
failing yet as I have not been able to add any debug to the code. But
the traceback is inside the setupDevice method for the VolumeGroupDevice.

A SystemError is being thrown for pvcreate failed.

The kickstart stanza is as follows:

part /boot --size=128 --asprimary --ondisk=sda --start=0 --fstype=ext3
part /boot1 --size=128 --asprimary --ondisk=sdb --start=0 --fstype=ext3

part swap --size=128 --ondisk=sda
part swap --size=128 --ondisk=sdb

part pv.01 --size=128 --grow --ondisk=sda
part pv.02 --size=128 --grow --ondisk=sdb
volgroup Main pv.01 pv.02
logvol / --vgname=Main --size=2048 --name=root --fstype=ext3
....

I am wondering if the grow settings on the pv's are casuing problems?
But have no further informaiton at present.



Version-Release number of selected component (if applicable):
9.92-8

How reproducible:
Always

Steps to Reproduce:
1. Set up a kickstart using test3 latest release
2. Use LVM to partition the disc except for the boot and swap
3. Allocate root into LVM and watch anaconda go futt.
    

Actual Results:  See above

Expected Results:  I had hoped to have a built system I could try out
some other kickstart facilities on.

Additional info:

I have patched anaconda to allow larger bootdisks, I am running with
RAMDISCS set to 32768k, the machines are dual processors (but that
does not seem relevant) and have pci=noacpi set to work. I have
patches for mkinitrd and new-kernel-pkg to make builds work with the
2.6.5 kernel.

Suspect an initialisation problem that setting up a raid or ordinary
partition first covers up, but have not found anything in reading the
source.
Comment 1 Howard Wilkinson 2004-05-02 14:15:47 EDT
More information. The failure is in the call to pvcreate which cannot
see partition /dev/sda2 (or /dev/sdb2). The pvcreate has problems with
the second partition on the disc it would seem as if I delete sda2 and
sda3 and recreate them the other way round, so that the LVM partition
is sda3 then pvcreate can see the partition. Adding a small dummy
partition  to the kickstart has the same effect.

Will test more later.
Comment 2 Howard Wilkinson 2004-05-03 03:44:44 EDT
Even more information. Problem is in the dev-cache code inside LVM2.
It seems to be unable to spot partitions that start on particular
boundaries on the discs, or something. So although the parition exists
and can be seen by fdisk, pvscan can't find it and pvcreate fails.
Need to reassign this bug to LVM2. Cylinder starting address of
failing partition is 17!

Trying for work rounds at present! Have confirmed that allowing the PV
to be allocated to extended partitions rather than primary works!
Also, assiging PV to a later cylinder works.
Comment 3 Alasdair Kergon 2004-05-26 11:50:46 EDT
lvm2 gets its partition information based on what's in /dev and what
the kernel sees.

If you add -vvv to the lvm2 command you can see which devices it finds
and what reason it gives for the ones it skips.  [Is the partition
table change getting picked up by the kernel?]
Comment 4 Alasdair Kergon 2004-08-31 09:58:50 EDT
Many changes since this was reported; assume it's no longer an issue.

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