Bug 36837 - Kickstart: too little free space in partitioning causes big mess
Summary: Kickstart: too little free space in partitioning causes big mess
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.0
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-20 14:22 UTC by Pekka Savola
Modified: 2007-03-27 03:43 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-05-02 05:05:56 UTC
Embargoed:


Attachments (Terms of Use)
%packges and %post have been snipped as they're of no consequence here (556 bytes, text/plain)
2001-04-22 06:06 UTC, Pekka Savola
no flags Details
%packges and %post have been snipped as they're of no consequence here (556 bytes, text/plain)
2001-04-22 06:07 UTC, Pekka Savola
no flags Details
packages and post have been snipped as they're of no consequence here (556 bytes, text/plain)
2001-04-22 06:11 UTC, Pekka Savola
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.