Bug 733791

Summary:	Kickstart option "part --onpart=LABEL=somelabel" is undocumented
Product:	[Fedora] Fedora	Reporter:	Andrew McNabb <amcnabb>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	16	CC:	anaconda-maint-list, jonathan, vanmeeuwen+fedora
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-15 19:04:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andrew McNabb 2011-08-26 21:23:02 UTC

While installing Fedora 16 Alpha, I found that partitions are being created out of order.  I used the following kickstart partitioning options:

zerombr
clearpart --linux --drives=vda --initlabel
part biosboot --fstype=biosboot --size=1
part /boot --fstype ext3 --ondisk=vda --asprimary
part / --size=20000 --fstype ext4 --ondisk=vda --asprimary
part swap --size=2048 --fstype swap --ondisk=vda --asprimary
part /local --size=100 --grow --fstype ext4 --ondisk=vda --asprimary --label=local

After partitioning, parted reports the following layout:

[anaconda root@localhost ~]# parted -s /dev/vda print all    
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 26.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  2097kB  1049kB                        bios_grub
 2      2097kB  21.0GB  21.0GB  ext4
 3      21.0GB  23.1GB  2147MB  linux-swap(v1)
 4      23.1GB  23.6GB  524MB   ext3            ext3  boot
 5      23.6GB  26.8GB  3197MB  ext4


[anaconda root@localhost ~]#

Notice that the boot partition is located after the swap partition instead of before the root partition.

This causes problems because I have a different kickstart script that uses existing partitions instead of repartitioning, but "part /boot --fstype ext3 --onpart=sda2" no longer works.

Comment 1 David Lehman 2011-08-26 22:39:52 UTC

There has never been any guarantee that partitions would be created in any particular order in anaconda or kickstart. If you want to be able to automate install/reinstall cycles you should consider using labels (user-specified) or uuids (automatically generated as part of filesystem) along with a %pre script to generate your partitioning commands.

Comment 2 Andrew McNabb 2011-08-28 03:13:04 UTC

I would love to use labels, but I cannot find any documentation about how to do this. As far as I understand from the Anaconda/Kickstart wiki page, the part --onpart requires a device name (from /dev) and does not support labels. What's the right way to specify a label?

Comment 3 Andrew McNabb 2011-08-30 16:37:06 UTC

I've finally had a chance to look into this more, and I eventually found a "part --onpart=LABEL=somelabel" option that seems to work. This was not in the Anaconda/Kickstart wiki page, so I just added it.

I will leave the ticket open because I have not tested the "part --onpart=UUID=someuuid" option, so I'd like someone who knows more about this to double-check my changes to the documentation.

Comment 4 Chris Lumens 2011-09-15 14:58:58 UTC

I've added a new section at the top that also includes some text out of the RHEL6 migration guide I think will be useful.  How does https://fedoraproject.org/wiki/Anaconda/Kickstart#Special_Notes_for_Referring_to_Disks look?

Comment 5 Andrew McNabb 2011-09-15 16:13:59 UTC

Overall, I think it's fantastic. My only thought is that the examples are prefixed with "/dev/disks", which seems to contradict the later warning: "Do not prefix the partition name with /dev." If the examples in the new section are correct, then it would be less confusing if the warning were fixed.

Comment 6 Chris Lumens 2011-09-15 19:04:03 UTC

Those warnings are no longer correct - you can use /dev/ if you want to.  It all gets resolved to the same devices internally.  I've removed those sentences.  Thanks for catching it.