Red Hat Bugzilla – Bug 53760
kickstart partitioning an already-partitioned disk fails
Last modified: 2005-10-31 17:00:50 EST
Description of Problem:
Kickstart partitioning of an already-partitioned disk fails in Fairfax IA-
64 RC1 (roswell2 - 18 August 2001).
At anaconda start, disk /dev/sda has three partitions on a GPT disk:
/dev/sda1 /boot/efi 100MB
/dev/sda2 swap 2047MB
/dev/sda3 / rest of disk
Kickstart file has the following:
# P A R T I T I O N S P E C I F I C A T I O N
part /boot/efi --ondisk sda --onpart sda1 --noformat
part / --fstype ext3 --size=1024 --ondisk=sda
part /usr --fstype ext3 --size=4096 --ondisk=sda
part swap --fstype swap --size=2048 --ondisk=sda
part /tmp --fstype ext3 --size=512 --ondisk=sda
part /var --fstype ext3 --size=64 --ondisk=sda --grow
This *should* clear the ext2/3 and swap partitions, but hopefully not the
EFI System Partition. I'd like to keep the existing EFI System Partition,
Anaconda displays the following message:
Unable to locate partition sda2 to use for /boot/efi
Clearly it's got some counting wrong, as sda1 should be /boot/efi.
The kernel has this message:
device busy for revalidation (usage=2)
df and /proc/mounts don't show anything mounted
/proc/modules shows that the megaraid module (where sda lives) has a use
count of 1.
/proc/partitions shows the three original partitions, sda.
parted /dev/sda print shows the disk has 0 partitions, and warns that the
kernel's idea of partitions was not updated.
Version-Release number of selected component (if applicable):
zerombr didn't act quite right in RC1, but this should be fixed now. I'll
double-check here once I finish running some other tests.
Yep, looks like it does the right thing with the current code base.