Bug 450504 - swap size not correct with --recommended
swap size not correct with --recommended
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-06-09 06:01 EDT by Alexander Todorov
Modified: 2008-08-11 13:02 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-11 13:02:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexander Todorov 2008-06-09 06:01:55 EDT
+++ This bug was initially created as a clone of Bug #445850 +++

+++ 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"

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-
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
+         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-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

-- Additional comment from atodorov@redhat.com on 2008-05-09 08:48 EST --
Created an attachment (id=304939)
log files from install

ks.cfg used to install contains:

clearpart --all --initlabel

part /boot --fstype ext3 --size=100   --asprimary
part swap --recommended --asprimary
part /	   --fstype ext3 --size=10000 --grow --asprimary

-- Additional comment from atodorov@redhat.com on 2008-05-09 08:53 EST --
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).

-- Additional comment from dlehman@redhat.com on 2008-05-12 18:24 EST --
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
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

-- Additional comment from atodorov@redhat.com on 2008-05-13 05:58 EST --
I'm able to create 10GB swap partition when performing the install manually on a
8GB system:
* Default settings (aka lvm layout) yields 10GB swap space
* Manual settings (disk druid) - swap, / (as primary) and /boot. swap is 10GB

The above kickstart code also yields around 22GB (21.96) swap partition on a
20GB system (as expected).

So the problem is only when using kickstart and raw swap partition, not lvm

-- Additional comment from dlehman@redhat.com on 2008-05-14 12:04 EST --
Have you tried the swap partition via kickstart without --asprimary?

-- Additional comment from dlehman@redhat.com on 2008-05-21 13:15 EST --
Martin, since you are at least within an hour or two of Alexander's timezone,
and since you fixed the original swap size bug, it makes sense for you to handle
this one.

-- Additional comment from dlehman@redhat.com on 2008-05-21 13:16 EST --
Whoops, I meant to do this along with the previous comment.

-- Additional comment from jgranado@redhat.com on 2008-06-04 13:45 EST --
Created an attachment (id=308376)
updates image.

Alex please test usiing this updates image.  it gives log messages.

-- Additional comment from jgranado@redhat.com on 2008-06-05 04:24 EST --
Created an attachment (id=308418)
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

-- Additional comment from jgranado@redhat.com on 2008-06-05 04:34 EST --
Created an attachment (id=308419)
new updates image with the log messages only

This updates image tracks the requestSize variable as well

-- Additional comment from jgranado@redhat.com on 2008-06-05 04:35 EST --
Created an attachment (id=308420)
updates with the kickstart.py file

This updates images tracks the requestSize and contains a patch for the
kickstart.py file

-- Additional comment from jgranado@redhat.com on 2008-06-05 10:15 EST --
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.
Comment 1 Alexander Todorov 2008-06-09 06:02:55 EDT
filed against F9, private comments stripped. 
Comment 2 Alexander Todorov 2008-06-09 06:04:03 EDT
clearpart --all --initlabel

part swap --recommended --asprimary
part /boot --fstype ext3 --size=100   --asprimary
part /     --fstype ext3 --size=10000 --grow --asprimary

with the above ks.cfg file on 54GB disk/8GB memory I get 1GB of swap, rest is
/boot and /
Comment 3 Alexander Todorov 2008-06-09 06:08:06 EDT
As per comment #2 I'd disagree with previous comment from Joel that the grow
part function grows partitions in the order it sees them.

Seems that the part grow function just grows / too much and there's nothing left
for swap. Even if I put swap first in the ks.cfg file results are not any better.

Could it be that partitions are reordered based on whether they are /, /boot or
swap? No matter how I reorder the lines in the above ks.cfg swap is always the
3rd partition on the disk.
Comment 4 Chris Lumens 2008-08-11 13:02:19 EDT
We've ported the fix from bug 447372 (which was filed against RHEL5) forward to Rawhide, so this should be better there.

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