Bug 478302

Created attachment 327884 [details]
Attached traceback automatically from anaconda.

When you hit this error, can you switch over to tty2 and see if /dev/sda2 even exists?

Chris,

I can switch to tty2.

The 'fdisk -l' output shows both a partitioning scheme for sda and sdb. Although I think this partitioning scheme is from a previous install.

Koos.

If I use this partitioning info in my kickstart file, I do not see the problem occuring.
==============================================================================================
zerombr yes
bootloader --location=mbr
clearpart --all --initlabel
part /boot --fstype ext3 --size=100
part pv.7 --size=0 --grow
volgroup VolGroup00 --pesize=32768 pv.7
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=1000 --grow --maxsize=1984
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
================================================================================================

If I use this partitioning info in my kickstart file, I do see the error.
================================================================================================
bootloader --location=mbr
clearpart --linux  --drives=sda
part /boot --fstype ext3 --size=100 --ondisk=sda
part pv.7 --size=0 --grow --ondisk=sda
volgroup VolGroup00 --pesize=32768 pv.7
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=1000 --grow --maxsize=1984
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
================================================================================================

I'm not sure if the output from fdisk really answers my question, though.  Can you ls /dev/sda* and see if all the device nodes are there?  Also, is this reproducable if you try to do the exact same install again?  Unfortunately, the lvm output is completely useless in this case.

ls /dev/sd* gives:
/dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1

This output is exactly how I would expect it to be.


This error is 100% reproducable. See my Comment #4 for my kickstart settings concerning the disk settings.

There was no error when I previously blanked out my harddisks with dd if=/dev/zero bs=1024k count=10 of=/dev/sd[a,b].

In that case anaconda asks to initialise the disks and continues with formatting and installing the system.

The problem seems to be related to the existance of partitions on the disks when installing.

I think we are hitting obsolete lvm metadata issues I've been
fixing for rhel5 recently. Perhaps we are not removing obsolete
VG - according to log, there is VolGroup00 found on sdb and we
try to create VolGroup00 on sda. Might be close to
https://bugzilla.redhat.com/show_bug.cgi?id=468431 and
https://bugzilla.redhat.com/show_bug.cgi?id=476582.
I am going to investigate a little more.

To Comment #8:

Should this mean, that if there is an other partitioning scheme on the discs, that this problem does not occure?

I'll try with only ext3 partitions on the disks as soon as I am back at my lab system.

Following comment #9:

As soon as I do not have Logical volume partitioning on the first harddisk. The error does not come up.

Created attachment 328557 [details]
log of reproducer with more info

I reproduced the bug with some more informative log info
from vgcreate command which suggests that comment #8 is
really the case.

I used the ks partitioning info from comment #4, tried to install
on a disk while having another one containing volume group
VolGroup00.

We have made extensive changes to the partitioning code for F11 beta, such that it is very difficult to tell whether your bug is still relevant or not.  Please test with either the latest rawhide you have access to or F11 and let us know whether you are still seeing this problem.  Thanks for the bug report.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping