+++ 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 on 2007-11-12 12:56 EST -- Martin, here's another one about swap and autopart. -- Additional comment from atodorov on 2008-02-06 04:55 EST -- qa_ack'ing, reproducer in comment #0 -- Additional comment from errata-xmlrpc 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 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 on 2008-04-29 08:03 EST -- moving back to assigned as per comment #4 -- Additional comment from atodorov 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 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 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 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).
Created attachment 304939 [details] log files from install ks.cfg used to install contains: zerombr clearpart --all --initlabel part /boot --fstype ext3 --size=100 --asprimary part swap --recommended --asprimary part / --fstype ext3 --size=10000 --grow --asprimary
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
Dave, 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
Have you tried the swap partition via kickstart without --asprimary?
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.
Whoops, I meant to do this along with the previous comment.
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.
Created attachment 308419 [details] new updates image with the log messages only This updates image tracks the requestSize variable as well
Created attachment 308420 [details] updates with the kickstart.py file This updates images tracks the requestSize and contains a patch for the kickstart.py file
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.
Filed against Fedora 9 as big #450504