Description of problem: When xfs partitions are bind mounted, leapp treats each one as an individual xfs partition. If we have ftype=0, then leapp assumes each one needs an overlay which increases the amount of space needed in /var/lib/leapp. This customer had 12 xfs partitions, but only 2 were valid. The other 10 were bind mounts. Leapp reported that we needed 36GB (With a 3G OVL size) in /var/lib/leapp but upon reboot, only used 6-7 GB (as the bind mounts were not in the fstab so do not mount upon boot). Version-Release number of selected component (if applicable): leapp-0.15.0-2.el7_9.noarch leapp-deps-0.15.0-2.el7_9.noarch leapp-upgrade-el7toel8-0.17.0-10.el7_9.noarch leapp-upgrade-el7toel8-deps-0.17.0-10.el7_9.noarch python2-leapp-0.15.0-2.el7_9.noarch How reproducible: Everytime Steps to Reproduce: 1. Have a system with ftype=0 on an xfs partition 2. bind mount any xfs partitions any number of times 3. leapp upgrade Actual results: ====> * target_userspace_creator Initializes a directory to be populated as a minimal environment to run binaries from the target system. 2023-04-27 10:24:27.525 ERROR PID: 12215 leapp.workflow.TargetTransactionFactsCollection.target_userspace_creator: Not enough space available for creating required disk images in /var/lib/leapp/scratch. Needed: 36864 MiB Expected results: We could base calculations off only whats in the fstab to avoid bind mounts. Or a warning that # bind mounts are present and affecting this size estimate. Additional info:
Lowering the priority as it's expected to be a corner case.