Bug 1871076 - Users of XFS file systems created with ftype=0 must lose a huge space in /var just for upgrading
Summary: Users of XFS file systems created with ftype=0 must lose a huge space in /var...
Keywords:
Status: ON_QA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: leapp-repository
Version: 7.8
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Leapp Notifications Bot
QA Contact: upgrades-and-conversions
URL:
Whiteboard:
Depends On:
Blocks: 1818077 1818088
TreeView+ depends on / blocked
 
Reported: 2020-08-21 09:42 UTC by Renaud Métrich
Modified: 2023-08-16 21:13 UTC (History)
5 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:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OAMG-3798 0 None None None 2023-05-11 08:07:19 UTC
Red Hat Knowledge Base (Solution) 5057391 0 None None None 2020-08-28 12:38:39 UTC

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.


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