+++ This bug was initially created as a clone of Bug #339001 +++
Description of problem:
According to the documentation for RHEL4, "Swap should equal 2x physical RAM for
up to 2 GB of physical RAM, and then 1x physical RAM for any amount above 2 GB"
(http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-install-guide/s1-diskpartitioning.html#S2-DISKPARTRECOMMEND)
However, on systems with >2G of RAM, only 2G is allocated when the "recommended"
option is used in kickstart configurations.
Version-Release number of selected component (if applicable):
Tested on, but not limited to RHEL 4.5, anaconda-10.1.1.63-4
I looked at RHEL5 and it has the same problem, but I didn't test it.
How reproducible:
Very consistently, unfortunately.
Steps to Reproduce:
Assuming you have PXE/kickstart environment set up already:
1. Create a kickstart file with the line:
part swap --recommended --asprimary
as the partitioning line for swap
2. PXE boot and kickstart a system with more than 2G of memory and sufficient
disk space such that the maximum amount of swap could be allocated (147G of
disk, for instance).
Actual results:
2G of swap.
Expected results:
More than 2G of swap (10G in the case of an 8G systems)
Additional info:
We use PXE boots with kickstart; non-interactive; partitioning line as mentioned
above; all systems with >2G of memory (usually 8G); all systems have >100G of
disk space.
The logic for determining swap size maximizes the swap at 2G (probably due to a
legacy filesystem size limit).
By applying the following patch to the stage2.img in the file
/usr/lib/anaconda/iutil.py, the correct amount of swap is created:
*** iutil.py- 1969-12-31 17:00:00.000000000 -0700
--- iutil.py 1969-12-31 17:00:00.000000000 -0700
***************
*** 256,259 ****
--- 256,264 ----
maxswap = 192
else:
+ if mem > 2000:
+ memextra = mem - 2000
+ minswap = 2000
+ maxswap = 4000 + memextra
+ else:
if mem > 1000:
minswap = 1000
Only tested on system with >2G of memory (4G and 8G). And isn't a megabyte 1024,
not 1000? :)
-- Additional comment from dlehman@redhat.com on 2007-11-12 12:56 EST --
Martin, here's another one about swap and autopart.
-- Additional comment from atodorov@redhat.com on 2008-02-06 04:55 EST --
qa_ack'ing, reproducer in comment #0
-- Additional comment from errata-xmlrpc@redhat.com on 2008-04-15 17:24 EST --
Bug report changed from MODIFIED to ON_QA status by the Errata System:
Advisory RHBA-2008:8333-01:
http://errata.devel.redhat.com/errata/show/7301
-- Additional comment from atodorov@redhat.com on 2008-04-24 09:40 EST --
Observations from latest 4.7 tree available:
environment: Xen/PV guest, i386, start up memory = maximum memory
mem: 8GB, install: manual, choose auto partition (e.g. lvm) - 10GB (as expected)
mem: 8GB, install: ks.cfg w/ swap --recommended - 8GB swap partition is created
mem: 5GB, install: manual, choose auto partition (e.g. lvm) - 7GB (as expected)
mem: 5GB, install: ks.cfg w/ swap --recommended - 7GB (as expected)
Only for the 8GB case the --recommended is not creating partition with the
expected size. Still investigating this with Martin to figure out what is wrong.
-- Additional comment from atodorov@redhat.com on 2008-04-29 08:03 EST --
moving back to assigned as per comment #4
-- Additional comment from atodorov@redhat.com on 2008-04-30 10:13 EST --
after more investigation I will move this to VERIFIED.
The swap calculation is fixed but there is a limit of 8GB hard coded in anaconda
hence the results in comment #4.
This limit is not documented and bug #437089 is used to track that.
-- Additional comment from dlehman@redhat.com on 2008-04-30 11:57 EST --
I still do not see where a limit of 8GB is enforced. The max size (maxSizeMB) in
fsset.swapFileSystem is 8TB, not 8GB.
-- Additional comment from msivak@redhat.com on 2008-05-02 05:12 EST --
Ups. you are right.. damn math. But even when it is not in the partitioning
limit, the limit is somewhat enforced during autopart.. but i have no idea
where. It works correctly during manual partitioning.
-- Additional comment from atodorov@redhat.com on 2008-05-05 07:25 EST --
wrt to comment #6:
the limit mentioned is the value of self.maxSizeMB in class swapFileSystem in
fsset.py which is actually 8TB not GB. Anyway something is preventing the
creation of swap partition larger than 8GB when using '--recommended'.
Using bug #437089 to document that. The problem reported with this bug was fixed
(i.e. the formula calculating the swap size was fixed to calculate the correct
size).

while bug #339001 fixes the formula for calculated the recommended swap size
there is something that prevents anaconda from creating swap partitions larger
than 8GB. I've tested with virtual guests with 8 and 10 GB of memory and the
result is almost the same - around 8GB of allocated swap space.
Manual install however is allocating the swap size as expected (i.e. 10GB swap
partition for 8GB memory) - see comments above. The problem is only when using
the --recommended option in kickstart.
The attached logs in comment #1 are from 8GB system. Also note that the
generated anaconda-ks.cfg files shows correct value for the swap partition (10GB).

Have you tried to create a swap partition of 10GB using the installer's manual
partitioning interface? I am starting to wonder if this limitation is being
imposed based on partition type as opposed to filesystem type.
Another interesting test would be to try the following partitioning info via
kickstart (you may need another PV depending on the disk layout, but you get the
main idea):
clearpart --all --initlabel
zerombr
part /boot --fstype ext3 --size=100
part pv.0 --size=0 --grow
volgroup VolGroup00 pv.0
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --recommended

Created attachment 308418[details]
The updates image with kickstart.py patched.
I found that in the kickstart.py file, unlike other parts of anaconda in 4.7,
the partRequest gets created without specifying the requestSize variable. This
updates image contains a patch kickstart.py file. Please test and see if the
bug reproduces with this updates image. It also containes additional log
information.

Found the reasoning for this issue:
background info:
When you use the "--recommended" argument in the kickstart file you are really
setting a startSize and a maxSize (this is done by a function that is equal in
lvm and partitions) and grow is set to True. After this is done it is up to the
grow function to make the sizes fit the disk or lvm volume group.
There are two grow functions:
The lvm grow function does its job by growing every partition in the proportion
of its current state.
The part grow function AFAIKS grows the partitions in order that it finds them,
so it first grows the "/" partition and then the "/boot" patition.... as it
finds them in the structure that holds that parititions that should be grown.
It will grow each partition by a half of its possible growth, check for validity
and continue to grow until it finds that the parition is invalid if it continues
to grow.
I think there is a case to be made here in the sense that the lvm grow and part
grow should be similar. But the last stages of rhel4 is not the place to do it.
I would put this into the long list of stuff to do for partitioning in fedora.