f377dd9ccb
- Require leapp-framework 6.0+ - Update leapp-deps package to satisfy leapp-framework-dependencies 6 - Add dependency on libdb-utils - Enable upgrade for systems with LUKS bound to Clevis with TPM 2.0 token - Adjust resource limitations for leapp to be able to perform the upgrade - Cap max size of the sparse files to 1TiB for storage with large amount of free space - Check that detected Intel CPU microarchitecture is supported on target system - Fix the report when handling broken parsing of kernel cmdline - Generate proper error message instead of ModelViolationError when parsing invalid repository definition - Handle default kernel cmdline when multiple boot entries for the default kernel are defined - Migrate Ruby IRB during the upgrade - Migrate pam_userdb backend during the upgrade - Skip checking of (PKI) `directory-hash` dir to speedup the upgrade process and clean logs - Update leapp upgrade data files - Resolves: RHEL-57043
67 lines
2.9 KiB
Diff
67 lines
2.9 KiB
Diff
From cef2825778eb63f95e13cf48b1683bc98c32c21b Mon Sep 17 00:00:00 2001
|
|
From: Michal Hecko <mhecko@redhat.com>
|
|
Date: Fri, 25 Oct 2024 16:33:38 +0200
|
|
Subject: [PATCH 15/40] lib(overlay): cap the max size of disk images
|
|
|
|
On systems with large disks (e.g. 16TB) with lots of free space, leapp
|
|
might attemt to create files larger than the max file size of the
|
|
underlying FS. Attempting to create such large files causes leapp
|
|
to crash. This patch caps the max image size to 1TB, based on empirical
|
|
evidence that more free space is not needed for the upgrade RPM
|
|
transaction.
|
|
|
|
Jira-ref: RHEL-57064
|
|
---
|
|
.../common/libraries/overlaygen.py | 28 +++++++++++++++++++
|
|
1 file changed, 28 insertions(+)
|
|
|
|
diff --git a/repos/system_upgrade/common/libraries/overlaygen.py b/repos/system_upgrade/common/libraries/overlaygen.py
|
|
index c1ac9ad3..867e3559 100644
|
|
--- a/repos/system_upgrade/common/libraries/overlaygen.py
|
|
+++ b/repos/system_upgrade/common/libraries/overlaygen.py
|
|
@@ -68,6 +68,27 @@ or close to that size, stay always with this minimal protected size defined by
|
|
this constant.
|
|
"""
|
|
|
|
+_MAX_DISK_IMAGE_SIZE_MB = 2**20 # 1*TB
|
|
+"""
|
|
+Maximum size of the created (sparse) images.
|
|
+
|
|
+Defaults to 1TB. If a disk with capacity larger than _MAX_DISK_IMAGE_SIZE_MB
|
|
+is mounted on the system, the corresponding image used to store overlay
|
|
+modifications will be capped to _MAX_DISK_IMAGE_SIZE_MB.
|
|
+
|
|
+Engineering rationale:
|
|
+ This constant was introduced to prevent leapp from creating files that are
|
|
+ virtually larger than the maximum file size supported by the file system.
|
|
+ E.g. if the source system hosts /var/lib/leapp on EXT4, then we cannot
|
|
+ create a file larger than 16TB.
|
|
+ We create these "disk images" to be able to verify the system has enough
|
|
+ disk space to perform the RPM upgrade transaction. From our experience,
|
|
+ we are not aware of any system which could have installed so much content
|
|
+ by RPMs that we would need 1TB of the free space on a single FS. Therefore,
|
|
+ we consider this value as safe while preventing us from exceeding FS
|
|
+ limits.
|
|
+"""
|
|
+
|
|
|
|
MountPoints = namedtuple('MountPoints', ['fs_file', 'fs_vfstype'])
|
|
|
|
@@ -287,6 +308,13 @@ def _prepare_required_mounts(scratch_dir, mounts_dir, storage_info, scratch_rese
|
|
disk_size = _get_fspace(mountpoint, convert_to_mibs=True, coefficient=0.95)
|
|
if mountpoint == scratch_mp:
|
|
disk_size = scratch_disk_size
|
|
+
|
|
+ if disk_size > _MAX_DISK_IMAGE_SIZE_MB:
|
|
+ msg = ('Image for overlayfs corresponding to the disk mounted at %s would ideally have %d MB, '
|
|
+ 'but we truncate it to %d MB to avoid bumping to max file limits.')
|
|
+ api.current_logger().info(msg, mountpoint, disk_size, _MAX_DISK_IMAGE_SIZE_MB)
|
|
+ disk_size = _MAX_DISK_IMAGE_SIZE_MB
|
|
+
|
|
image = _create_mount_disk_image(disk_images_directory, mountpoint, disk_size)
|
|
result[mountpoint] = mounting.LoopMount(
|
|
source=image,
|
|
--
|
|
2.47.0
|
|
|