Bug 445850
| Summary: | swap size limited to 8GB with --recommended | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Alexander Todorov <atodorov> | ||||||||||
| Component: | anaconda | Assignee: | Martin Sivák <msivak> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 4.5 | ||||||||||||
| Target Milestone: | rc | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2008-06-05 14:23:13 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
Alexander Todorov
2008-05-09 12:47:09 UTC
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 |