Red Hat Bugzilla – Bug 1262098
/boot partition is too small (200MB) when using custom partitioning
Last modified: 2015-10-20 23:25:14 EDT
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):
Steps to Reproduce:
Boot partition too small.
Request a Boot Partition of approx 500 MB.
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?
To be considered for inclusion in the 21.1 bugfix release.
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.
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:
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.
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).
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:
RHEL7: fstype=xfs (fstype=ext4 should be fine too)
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.
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.
Beaker 21.1 has been released.