Bug 7155
Summary: | partition order in kickstart | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Vilius Puidokas <knopka> |
Component: | installer | Assignee: | Matt Wilson <msw> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | drdisk, jorma.laaksonen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-02-22 17:16:05 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
Vilius Puidokas
1999-11-19 21:13:53 UTC
This issue has been forwarded to a developer for further action. As for rescue mode, we included that on the installation media, so instead of having to have a system-specific boot disk and the rescue.img disk, you just have to type "linux rescue" at the boot prompt. This will load the rescue image from the installation source and allow you to use the rescue functions. (a little workaround i've found) I noticed that bug is about maxof(--size). looks like hda1 is always largest partition (non --grow). say i do: part / --size 250 ; i'm making it largest part /var --size 100 part swap --size 100 part /swapfil --size 100 part /usr --size 200 --grow --maxsize 800 ; (--maxsize is buggy also) part /tmp --size 100 part /export --size 100 --grow now, hda1 is / if you make a partition /boot kickstart will put it in /dev/hda1 and lilo can boot ok. It would be better if kickstart simply made partitions in the order specified in the file. Why do you sort it to make the largest first? For now you can use this patch. This behaviour has annoyed me since DiskDruid/ kickstart has been introduced. When kickstarting machines, I really have an idea on *why* putting partitions in a certain order. If at least this behaviour would be manually configurable for kickstart installs... Something along the lines of %option libfdisk -sizesort or similar. Maybe adding some flags attribute to struct fdisk_partition would be a good idea, so that one can expicitly specify if the partition should be sorted by size or not. We could use this flags attribute for other things too. --- anaconda/libfdisk/partspec.c.nosizesort Fri Nov 26 13:03:44 1999 +++ anaconda/libfdisk/partspec.c Fri Nov 26 13:07:40 1999 @@ -101,10 +101,16 @@ f = 1; else if (pri1 > pri2) f = -1; + +/* Sorting by size is *really* annoying and a PITA when doing kickstart installs, + since I order the partitions for a reason, e.g. swap areas at the end of a + disk are just plain stupid. */ +#if 0 else { fdiskGetConstraint(&p2->size,&csize2,&lsize2,&msize2,&act2 ); f = (lsize1 < lsize2); } +#endif if (f > 0) { memcpy(&tmpe, &spec->entry[i], sizeof(PartitionSpecEntry)); [ This issue has been forwarded to a developer for further action. We have added an "--onpart" argument to kickstart which will enable you to specify which partition will get each partition that you are specifying in the ks.cfg file. This will help to avoid the problem that you are having. In addition, the drive space placement argorithm has been improved and now places the /boot or root (if /boot is not separate partition) below the 1024 cylinder limit. |