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.
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.
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.
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?]
Many changes since this was reported; assume it's no longer an issue.