2134213 – [RFE] leapp should adjust the OVL size based on partitions and package installations.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2134213 - [RFE] leapp should adjust the OVL size based on partitions and package installations.

Summary: [RFE] leapp should adjust the OVL size based on partitions and package instal...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	leapp-repository
Sub Component:
Version:	7.9
Hardware:	Unspecified
OS:	Unspecified
Priority:	low
Severity:	urgent
Target Milestone:	rc
Target Release:	---
Assignee:	Petr Stodulka
QA Contact:	upgrades-and-conversions
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2022-10-12 19:27 UTC by jcastran
Modified:	2023-11-16 06:56 UTC (History)
CC List:	3 users (show)
Fixed In Version:	leapp-repository-0.18.0-5.el7_9
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2023-11-16 06:56:41 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	OAMG-7736	None	None	None	2022-10-12 19:37:08 UTC
Red Hat Issue Tracker	RHELPLAN-136278	None	None	None	2022-10-12 19:37:05 UTC
Red Hat Knowledge Base (Solution)	5057391	None	None	None	2022-10-12 19:27:49 UTC

Description jcastran 2022-10-12 19:27:50 UTC

~~~~~~~~~~~~~~~~
Description of problem:
~~~~~~~~~~~~~~~~
Currently leapp defaults to a 2GB LEAPP_OVL_SIZE (overlay size) which often results in:

   At least 1044MB more space needed on the / filesystem.

This can occur for 1 of two reasons
 - Not enough physical space on the system
 - Not enough space in the overlay fs for the packages being installed.

For customers who have ftype=0 xfs partitions, it means the system has 2GB to install the sometimes 1500+ packages on a system.

- - - - - - - - - 
Secondarily, leapp does not verify or make it clear the overlay's it's going to make or how much space will be consumed in /var. 


~~~~~~~~~~~~~~~~
Recommended Resolution:
~~~~~~~~~~~~~~~~
* The logic could be improved to determine a better rough estimate of space needed for packages, then automatically increase the size of LEAPP_OVL_SIZE for the upgrade.

* It should also verify that there is enough space in /var/lib/leapp to hold all of the overlay images that leapp is going to create.

If either of these is not possible, there should be a clear message telling the customer (And the engineers) what the issue is.

  a LEAPP_OVL_SIZE of 4096 is recommended for this upgrade based on your partitioning layout. This requires 20GB in /var/lib/leapp . Currently only 15GB is free. Free up space in $(df -h /var/lib/leapp), or create a dedicated /var/lib/leapp partition over 20GB in size to hold the recommended overlays for this upgrade.

~~~~~~~~~~~~~~~~
Note
~~~~~~~~~~~~~~~~
This is the number one issue with leapp that I see. Most of the time it results in making a dedicated /var/lib/leapp partition, and increasing LEAPP_OVL_SIZE by 1GB until it has enough space for all the packages being installed.

    [leapp] At least X MB more space needed on the </XXX> filesystem
    https://access.redhat.com/solutions/5057391

Comment 3 Petr Stodulka 2022-10-13 08:25:24 UTC

Hi John, thank you for the report. I am lowering severity and priority (it's not a blocking customers, it's documented in the official upgrade documentation, and it's rfe).

Regarding the provided msg, we have already opened PR in upstream to improve it:
    https://github.com/oamg/leapp-repository/pull/956
We are working on improvements in this area continuously (see related bzs below).

Related BZs:
    https://bugzilla.redhat.com/show_bug.cgi?id=2110045
    https://bugzilla.redhat.com/show_bug.cgi?id=1832730
    https://bugzilla.redhat.com/show_bug.cgi?id=1871076

Additional info:
   This is not a duplicate of mentioned bugs as the requested solution
   is to automatically increase the size of the underlying images
   in a safe way (so not all space is consumed) which is not part
   of the other bugs.

   Any other improvements in this area should first introduce a better
   solution that does not consume 2GiB + 2GiB per partition formated
   with XFS without ftype attributes.

Comment 6 Kyle Walker 2022-10-13 14:09:16 UTC

@Petr
I raised the Severity back up. It is an exceptionally severe problem, even if just as reported by Support Delivery. I left the Priority to reflect your teams evaluation of the BZ/RFE.

The error message improvement looks great! I can also see how it could be seen as an RFE versus a BZ. I would lean more heavily in the direction of a BZ though. Primarily in that the current implementation is completely static where the input factors are dynamic. The tool doesn't attempt to figure out how much space is necessary at all, it just creates a 2Gib overlay mount...

The tooling has access to an approximate amount of space necessary to install. With the transaction prepared, simply verify the installed RPMs size. It seems pretty straightforward to me to simply calculate the necessary size and then add a bit of overhead on top. You should have a reasonable idea of what the size should be, which could then be overridden in the event of a corner-case.

Comment 10 Petr Stodulka 2023-07-17 19:34:44 UTC

The original solution has been redesigned and should be fixed by upstream PR:
  https://github.com/oamg/leapp-repository/pull/1097

All created OVL images are represented by sparse-files now. In many cases it should mean less consumed space and all previous problems with too greedy OVL images should be fixed. However for systems without old XFS filesystems and many partitions will be requirements higher - approx 128 MB per partition/volume specified in fstab. This value could be possibly yet lowered, but for now let's go with this.

Comment 15 errata-xmlrpc 2023-11-16 06:56:41 UTC

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 (leapp and leapp-repository bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2023:7230

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