Hide Forgot
Insufficient `/boot` partition size may prevent the system from upgrading The `/boot` partition, which contains installed kernels and initial ram disks, may become full if multiple kernels and additional packages such as _kernel-debug_ are installed. This is caused by the default size of this partition being set to 500 MB during installation, and prevents the system from being upgraded. As a workaround, use "yum" to remove older kernels if you do not need them. This known issue only affects installation made with Red Hat Enterprise Linux 7.2 and earlier. In Red Hat Enterprise Linux 7.3, the default size of the `/boot` partition is increased to 1 GB, which avoids this problem in future upgrades.
Description of problem: If user creates 500MB /boot partition, which is default in RHEL-7, it might be not enough and errors can be seen during the future upgrades. This will happen for example if user has also kernel-debug package installed. See the analysis below. Version-Release number of selected component (if applicable): RHEL-7.1, RHEL-7.2 How reproducible: always Steps to Reproduce (real use case): 1. Start installation of RHEL-7.1, select kernel-debug to be installed (or install all packages). Anything works 2. Register to RHSM, update system to latest 7.1.z version 3. Once new Z-Stream batch is released, or once 7.2 is released, update system again. Actual results: After installation: Total space: 497MB Used space: 216MB (44%) Free space: 282MB After upgrade to latest 7.1.z: Total space: 497MB Used space: 397MB (80%) Free space: 100MB Next upgrade fails with: Transaction check error: installing package kernel-debug-3.10.0-320.el7 needs 27MB on the /boot filesystem Expected results: Updates of RHEL-7 should be working without issues even when kernel-debug package is installed. RHEL-7 is set to keep 3 kernels installed (based on /etc/yum.conf). /boot partition should be big enough to fit 3 kernels (with all variations) Additional info:
Expected Result: 1G /boot partition should accomodate 3 kernels without issues.
See also: BZ1262098 [1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=1262098
Are there any platform-specific concerns over growing the size of /boot? Will all architectures still be able to see and boot from a filesystem of that size?
This requires the following patch be applied to blivet: diff --git a/blivet/platform.py b/blivet/platform.py index 8363c0d..df903f5 100644 --- a/blivet/platform.py +++ b/blivet/platform.py @@ -165,7 +165,7 @@ class Platform(object): def set_platform_boot_partition(self): """Return the default /boot partition for this platform.""" - return [PartSpec(mountpoint="/boot", size=Size("500MiB"), + return [PartSpec(mountpoint="/boot", size=Size("1GiB"), weight=self.weight(mountpoint="/boot"))] def set_default_partitioning(self): @@ -360,7 +360,7 @@ class S390(Platform): def set_platform_boot_partition(self): """Return the default platform-specific partitioning information.""" - return [PartSpec(mountpoint="/boot", size=Size("500MiB"), + return [PartSpec(mountpoint="/boot", size=Size("1GiB"), weight=self.weight(mountpoint="/boot"), lv=False)] def required_disklabel_type(self, device_type):
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2168.html