Bug 36837

Summary: Kickstart: too little free space in partitioning causes big mess
Product: [Retired] Red Hat Linux Reporter: Pekka Savola <pekkas>
Component: anacondaAssignee: Brent Fox <bfox>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: high    
Version: 7.0   
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: 2001-05-02 05:05:56 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:
Attachments:
Description Flags
%packges and %post have been snipped as they're of no consequence here
none
%packges and %post have been snipped as they're of no consequence here
none
packages and post have been snipped as they're of no consequence here none

Description Pekka Savola 2001-04-20 14:22:20 UTC
On 6.4 GB drive I had:

part / --size 1024
part swap --size 512
part /tmp --size 512
part /config --size 1024
part /var --size 3072
part /opt --size 1 --grow

There is enough space for everyone.  (Though the partitioning is clearly
optimized for bigger disks).

Now, kickstart creates the partitions very recklessly.  / partition isn't
first on the disk.  I don't have this here at the moment, but I recall the
partitions were ordered from the biggest to the smallest, like /var hda1,
etc. Adding /boot makes the installed system bootable, but not necessarily
sane. You can't control the ordering.

If you reduce the sizes, like:

part / --size 1024
part swap --size 512
part /tmp --size 512
part /config --size 512
part /var --size 500
part /opt --size 1 --grow

, or install on a bigger disk, you get what you expect:

/dev/hda1	/
/dev/hda5	swap
/dev/hda6	/tmp
/dev/hda7	/config
/dev/hda8	/var
/dev/hda9	/opt

(in the order they were defined in ks.cfg).

Haven't checked whether 7.1 is similarly affected.

Comment 1 Brent Fox 2001-04-20 15:12:09 UTC
http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/s1-kickstart2-commands.html

Take a look at the above URL for kickstart documentation.  You can make
kickstart do what you want it to by passing in various options.  If you want /
to be created first, you can use the --onprimary <N> flag.  Does this fix your
problem?


Comment 2 Pekka Savola 2001-04-21 18:54:29 UTC
That does not work properly.  If you define:

part / --size 1024 --onprimary 1
part swap --size 512
[and so on]

The auto-partitioning will fail if the partitions exists even though there is 'clearpart --all' with:

Failed to allocate '/': No free primary


Comment 3 Brent Fox 2001-04-21 23:26:29 UTC
Can you attach your complete kickstart file?

Comment 4 Pekka Savola 2001-04-22 06:06:31 UTC
Created attachment 16005 [details]
%packges and %post have been snipped as they're of no consequence here

Comment 5 Pekka Savola 2001-04-22 06:07:08 UTC
Created attachment 16006 [details]
%packges and %post have been snipped as they're of no consequence here

Comment 6 Pekka Savola 2001-04-22 06:11:59 UTC
Created attachment 16007 [details]
packages and post have been snipped as they're of no consequence here

Comment 7 Pekka Savola 2001-04-22 06:16:02 UTC
Whoops.  Attaching seemed to freeze but apparently it works.

Comment 8 Brent Fox 2001-05-01 21:44:12 UTC
I just did a minimal kickstart install with your kickstart file with no
problems.  Here's what df says on that system:

/dev/hda1              1035660    157916    825136  17% /
/dev/hda6              1035660        20    983032   1% /config
/dev/hda9              3621020        20   3437060   1% /opt
/dev/hda8               521748        24    495220   1% /tmp
/dev/hda5              3099260      4172   2937656   1% /var


Comment 9 Pekka Savola 2001-05-02 05:05:52 UTC
Yeah, that works.

Try to install on a smaller HDD, like 6.4 GB, and there _should_ be problems.  Other way to incite get on the one you currently are using
might be to make bigger partitions.  I'm guessing:

 part / --size 2048
 part swap --size 512
 part /tmp --size 512
 part /config --size 2048
 part /var --size 4096
 part /opt --size 1 --grow

would be enough (/opt would be like 600 megs)

Reopening just in case.


Comment 10 Brent Fox 2001-05-08 19:58:52 UTC
Yes, I see what you mean.  A complete rework of the partitioning subsystem is on
the drawing board, so I expect this problem to be fixed by that.  As such,
there's not much use in patching the existing code.  Thanks for your report.