Bug 1262098 - /boot partition is too small (200MB) when using custom partitioning
Summary: /boot partition is too small (200MB) when using custom partitioning
Alias: None
Product: Beaker
Classification: Retired
Component: general
Version: 21
Hardware: ppc
OS: Linux
Target Milestone: 21.1
Assignee: Dan Callaghan
QA Contact: tools-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2015-09-10 19:34 UTC by Anthony Gialluca
Modified: 2015-10-21 03:25 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-10-21 03:25:14 UTC

Attachments (Terms of Use)
job xml to verify (6.61 KB, text/plain)
2015-10-09 03:43 UTC, Dan Callaghan
no flags Details

Description Anthony Gialluca 2015-09-10 19:34:26 UTC
Description of problem:
system generates following kickstart
options for storage:
clearpart --drivesystem generates following kickstart
options for storage:
clearpart --drives sda --all --initlabel

part None --fstype 'PPC PReP Boot' --size 8 --ondisk=sda
part /boot --size 200 --recommended --asprimary --ondisk=sda
part / --size 1024 --grow --ondisk=sda
part swap --recommended --ondisk=sda

Boot partition is too small to install 2nd RHEL7 kernel, which is causing
KT1 jobs to abort.

Version-Release number of selected component (if applicable):

How reproducible:
Always reproducible.

Steps to Reproduce:

Actual results:
Boot partition too small.

Expected results:
Request a Boot Partition of approx 500 MB.

Additional info:

Comment 2 Dan Callaghan 2015-09-17 01:45:14 UTC
My preferred solution is drop --size 200, leaving --recommended, for the /boot line. Need to check:

* does RHEL have a documented minimum or recommended size for /boot?
* will all Anaconda releases use a sensible size if we have --recommended and no --size?

Comment 3 Roman Joost 2015-09-17 01:46:04 UTC
To be considered for inclusion in the 21.1 bugfix release.

Comment 4 Dan Callaghan 2015-10-06 01:22:24 UTC
There is no reason to think that this only affects ppc64, except that maybe the ppc64 kernels are bigger than others so that's the first place we hit this problem.

Comment 5 Dan Callaghan 2015-10-06 01:39:07 UTC
RHEL6 docs recommend 250MB for /boot, and indicate that each kernel consumes 10MB.


For RHEL7 the recommendations were doubled (20MB for each kernel, 500MB for /boot):


RHEL5 recommended 100MB for /boot/efi on ia64, 100MB for /boot on POWER, and 250MB for /boot on x86 (but the inconsistencies are probably just a docs bug):


RHEL3 and RHEL4 docs recommended 100MB:


Comment 6 Dan Callaghan 2015-10-06 05:10:43 UTC
Unfortunately in RHEL up to RHEL6 the --recommended option for the part command doesn't actually have any effect for partitions other than swap (contrary to what the docs indicate).

The installation bails out with:

Partition requires a size specification

Newer Anaconda in RHEL7/Fedora happily accepts the --recommended option, it seems to pick 500MB for the partition size which matches the recommendation in the docs.

So it looks like we can have --recommended without --size by default, with some hardcoded sizes as a fallback on older RHELs.

Comment 7 Dan Callaghan 2015-10-06 05:12:37 UTC
I guess we will want to use 200MB for RHEL3 and RHEL4 (which is larger than the recommended size, but it matches Beaker's current behaviour), 250MB for RHEL5 (matching the recommendation for x86, assuming that the 100MB recommendation for some arches was a mistake), and 250MB for RHEL6 (matching the recommendation).

Comment 8 Dan Callaghan 2015-10-06 07:37:02 UTC

Comment 9 Dan Callaghan 2015-10-09 03:40:39 UTC
Steps to verify:
Run a recipe on all supported distros, use fstype= to trigger custom partitioning, use /distribution/command to check size of boot partition using "df -h".
Because each release has different supported filesystems we need different fstype= values:
RHEL4: fstype=ext3
RHEL5: fstype=ext3
RHEL6: fstype=ext4
RHEL7: fstype=xfs (fstype=ext4 should be fine too)
F18: fstype=ext4
F19: fstype=ext4
F20: fstype=ext4
F21: fstype=ext4
F22: fstype=ext4

Expected results:
On Fedora and RHEL7, the generated kickstart should contain a line like this (no --size option):
part /boot --fstype ext4 --recommended --asprimary
and the resulting boot partition size should be 500MB.

On RHEL5/6 the kickstart should contain a line like:
part /boot --fstype ext4 --size 250 --recommended --asprimary
and the resulting boot partition size should be 250MB.

On RHEL3/4 the kickstart should contain a line like:
part /boot --fstype ext3 --size 200 --recommended --asprimary
and the resulting boot partition size should be 200MB.

RHEL3 is optional at this point because we are no longer supporting it.

Comment 10 Dan Callaghan 2015-10-09 03:43:46 UTC
Created attachment 1081177 [details]
job xml to verify

This is the job XML I ran in my Beaker environment to verify.

I was seeing an issue with the Fedora installations randomly failing with an Anaconda error like this:

IOException: Partition(s) 5 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

but I don't think it's related to this patch. I can see from the Anaconda logs that it was going to use 500MB as the boot partition size (as expected). There are also many old and not fully resolved Fedora bug reports about this error. I suspect it is something specific to the VM setup I have in my Beaker environment.

Comment 14 Dan Callaghan 2015-10-21 03:25:14 UTC
Beaker 21.1 has been released.

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