Bug 1871076

Summary: Users of XFS file systems created with ftype=0 must lose a huge space in /var just for upgrading
Product: Red Hat Enterprise Linux 7 Reporter: Renaud Métrich <rmetrich>
Component: leapp-repositoryAssignee: Leapp Notifications Bot <leapp-notifications-bot>
Status: CLOSED ERRATA QA Contact: upgrades-and-conversions
Severity: high Docs Contact:
Priority: high    
Version: 7.8CC: cbesson, croadfel, fkrska, mmoran, pholica, pstodulk
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: leapp-repository-0.18.0-5.el7_9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-11-16 06:56:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1818077, 1818088    

Description Renaud Métrich 2020-08-21 09:42:17 UTC 
Description of problem:

When a system has XFS file systems created with "ftype=0" attribute (e.g. system was installed with < RHEL 7.5) and file system hierarchy is split (e.g. /usr, /var, /var/log, ...), it's not possible to upgrade to RHEL 8.2 unless /var file system hosting /var/lib/leapp is extended by several Gigabytes.
This is not acceptable since XFS file systems can be shrinked once extended afterwards.

Example:

Customer has /, /usr, /var, /var/log, /opt which is very common when sticking to STIG recommendations.
These 5 file systems will require an additional 5 x 2GB (LEAPP_OVL_SIZE) = 10GB on /var to host the temporary disk images.

Now say 2GB LEAPP_OVL_SIZE is not sufficient due to having many packages (e.g. "Server with GUI" installation was used), consuming a lot of space in /usr.
With LEAPP_OVL_SIZE enlarged to 4GB (our usual recommendation), up to 20GB additional space on /var must be needed to host the temporary disk images.

There are multiple solutions to this issue:

Solution 1: be able to specify LEAPP_OVL_SIZE variable per XFS file system (some file systems do not require much disk image)

  This solution would be suitable when Volume Group has not much free space and /var cannot be extended much more.

Solution 2: create a temporary file system mounted on /var/lib/leapp to host the disk images

  This solution would be suitable when Volume Group / local disk has enough free space to hold a new volume until the upgrade is completed.
  The customer can then trash the temporary file system once upgrade finished.
Comment 9 Petr Stodulka 2023-07-17 19:39:04 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. All systems originally affected by this ticket will consume just a fraction of original requriements - 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 12 Chris Roadfeldt 2023-08-16 21:13:43 UTC 
This is affecting RHEL 8 to RHEL 9 as well.
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