What does your kickstart look like? In the past this has usually been a side-effect of referencing the same repos multiple times. We try to detect that and remove the duplicates, but if the paths are not exactly the same they are left alone.

Calculating disk size is difficult, and we already over-estimate the size even compared to what anaconda estimates when doing its check.

See: https://github.com/weldr/lorax/blob/rhel7-extras/src/pylorax/api/compose.py#L408

Please find the customer KS in a private attachment.

It doesn't seem to have repos referenced multiple times. The default rootfs partition in this case is:
part / --size=2139

Thanks, that doesn't look unreasonable. But I'm afraid I really don't have a solution for this at the moment.

I just tested an install with this kickstart (with my own repos), here is what I got from the anaconda.log:

00:29:56,060 INFO anaconda: fs space: 2139 MiB  needed: 2861.02 MiB
00:29:56,077 ERR anaconda: Not enough space in file systems for the current software selection. An additional 722.02 MiB is needed.

I don't know how to get this estimation given by Anaconda, but hopefully it might help.

I don't understand of all the parts of the calculation in the lorax code (and not the time to do so). So I wrote a simple "kscheck" script which uses the same libraries than lorax (yum.YumBase() among others...).

Based on the customer KS, I got a template size of 1390343677 bytes, ~1400 MB. But I think this value doesn't take into account the corresponding yum cache:
# du -hs /var/tmp/kscheck/root/var/cache/
701M	/var/tmp/kscheck/root/var/cache/

Coincidently, the cache size corresponds to the lack of space in the rootfs. Can it be the reason?

I think additional space is also needed for the operations themselves (possibly temporary uncompressing, logging, ...). In addition to the 40% margin, why not adding a hardcoded 1GB for / ?

Created attachment 1626479 [details]
small script to compute the installed size as yum does

Well, I agree on the fact it's difficult to estimate the image size automatically :)

I modified my script to compute separately the installed size for the "core" yum group (I basically got 644484314).
And the installed size of the ks's packages is 910028980.

((644484314+910028980)*1.4)/(1024*1024) = 2075, which is very close to what you get for the rootfs size (2139 according to the ks). 

I really think the difference comes from the yum cache since it is a network install, and packages have to be downloaded in the cache first. Indeed, I also checked the size of the RPM packages of the core group, I got 152 MB:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
yb.selectGroup("core", group_package_types=['mandatory', 'default', 'optional'])
(rc, msg) = yb.buildTransaction()
if rc not in [0, 1, 2]:
        sys.exit(1);
yb.tsInfo.makelists()
installed_size = 0
pkg_core_size = 0
for pkg in yb.tsInfo.installed:
        pkg_core_size += pkg.po.size                       <========
        installed_size += pkg.po.installedsize
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So I suppose the remaining lack of space mainly comes from the size of packages defined in the kickstart.

HTH.

What do you think of this patch?

diff -up lorax-19.7.25/src/pylorax/api/projects.py.cachesize lorax-19.7.25/src/pylorax/api/projects.py
--- lorax-19.7.25/src/pylorax/api/projects.py.cachesize	2019-10-16 18:29:35.000000000 +0200
+++ lorax-19.7.25/src/pylorax/api/projects.py	2019-10-16 18:32:03.000000000 +0200
@@ -233,9 +233,12 @@ def estimate_size(packages, block_size=4
     a minimum size for each package.
     """
     installed_size = 0
+    cache_size = 0
     for p in packages:
         installed_size += len(p.po.filelist) * block_size
         installed_size += p.po.installedsize
+        cache_size += p.po.size
+    installed_size += cache_size
     return installed_size
 
 def projects_depsolve_with_size(yb, projects, with_core=True):

Finally, I tried it and it "works for me".

Without the patch, the rootfs part size in the final-ks.cfg is 2139 MB.
By adding the size of all downloaded packages (provided by po.size), I got 2829 MB.
But it still lacks 10 small MB, despite the original over-estimation of 40%, and I didn't understand why. So I also changed that to 50%, and I got a rootfs part size of 3031 MB, which is enough. 
Please note I only tested my patch with the ami.ks template.


--- lorax-composer-19.7.35/src/pylorax/api/compose.py.cachesize	2019-10-17 14:58:37.000000000 +0200
+++ lorax-composer-19.7.35/src/pylorax/api/compose.py	2019-10-17 14:59:22.000000000 +0200
@@ -404,8 +404,8 @@ def start_build(cfg, yumlock, gitlock, b
         raise RuntimeError("Problem depsolving %s: %s" % (recipe["name"], str(e)))
     log.debug("installed_size = %d, template_size=%d", installed_size, template_size)
 
     # Minimum LMC disk size is 1GiB, and anaconda bumps the estimated size up by 35% (which doesn't always work).
-    installed_size = max(1024**3, int((installed_size+template_size) * 1.4))
+    installed_size = max(1024**3, int((installed_size+template_size) * 1.5))
     log.debug("/ partition size = %d", installed_size)
 
     # Create the results directory
diff -up lorax-composer-19.7.35/src/pylorax/api/projects.py.cachesize lorax-composer-19.7.35/src/pylorax/api/projects.py
--- lorax-composer-19.7.35/src/pylorax/api/projects.py.cachesize	2019-10-17 14:58:52.000000000 +0200
+++ lorax-composer-19.7.35/src/pylorax/api/projects.py	2019-10-17 14:59:55.000000000 +0200
@@ -360,9 +360,12 @@ def estimate_size(packages, block_size=4
     a minimum size for each package.
     """
     installed_size = 0
+    cache_size = 0
     for p in packages:
         installed_size += len(p.po.filelist) * block_size
         installed_size += p.po.installedsize
+        cache_size += p.po.size
+    installed_size += cache_size
     return installed_size
 
 def projects_depsolve_with_size(yb, projects, groups, with_core=True):

Thanks for looking at this, you may be on the right track, but I'm worried that the +40% isn't enough (Anaconda only adds 35% for example). That means that there are probably other situations where it can fail.

Ok, I think this is much closer to being generally reliable. anaconda is writing the cached rpms to the disk, as you discovered, but it is also writing the repo metadata. This may explain why installations with large numbers of repos have more problems than those with two or three.

Could you add this commit:

https://github.com/weldr/lorax/pull/875/commits/2d7a972aab0097ffe86c9a30714bfdc3e3d62333

from https://github.com/weldr/lorax/pull/875

and remove the change from 40% to 50% that you added to the estimate.

Yes the metadata size, obviously! I rebased my pull request with your commit and removed the change I added to the estimate:
https://github.com/weldr/lorax/pull/874

(not sure if this is exactly what you expected)

I made a first try in my environment, and the value I got for the rootfs size is 5563 MB, which is enough... and even too large. I think there are still remaining problems:
- After a look in the master branch, it appears that anaconda bumps the estimated size up to 10% (not 35%) and the lorax code of the master branch does +20% instead of +40%.
- I'm not sure the estimate of each file of a given package * block_size is still relevant.
- After a little trace, I noticed core packages (e.g. bash) are counted twice.
- The patch you suggest seems to add the whole size of the default rootfs, so it always adds 2GB. For me, it's different from the metadata itself, and it is not really satisfying.

I made another try by computing the metadata of each repo, this time I got 3148 MB (with a bump of "only" 40%). So I'm going to update my commit with this new proposal patch. Please let me know what you think about it.

Done in this commit:
https://github.com/weldr/lorax/pull/874/commits/bb7a5d39519052c9971e5f4f48b63fa75aeb9595

=> let me know your review, and if I should squash my both commits into a single one.

Well, still a last change.

The list of repos being already known from compose.py, it is really better to do that (so there is no change on the prototype/return of the depsolve_with_size function):
https://github.com/weldr/lorax/commit/df3de2e0abe794f5b193afa6c2589d55213c32e5

Again, please let me know your review, and if I should squash my both commits into a single one.

I continue again... Just fixed the lack of metadata_size in the final computing + log.debug instead of log.info.
https://github.com/weldr/lorax/pull/874

A last thought. I can't find out if the size of "installroot" (as seen in your commit) may change. I think it already contains "core installed_size" + metadata_size and possible temporary files that we can't estimate properly.
So with an installed_size of (installroot + template_size) * 1.2 [as it is done in the master branch], that could give a good estimate (and this way, we can probably avoid the duplicate count of core installedsize packages).

Updated PR - https://github.com/weldr/lorax/pull/875

Ends up lorax-composer includes the filelists (which it needs to accurately estimate the size taken up by individual files) and 'other' which is the changelog. Removing those from the metadata estimates matches what anaconda downloads, so this should be fairly accurate. It also makes sure that it doesn't used a size smaller than what anaconda would estimate -- if it did, the install would fail.

*** Bug 1811273 has been marked as a duplicate of this bug. ***

*** Bug 1694066 has been marked as a duplicate of this bug. ***

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 (lorax-composer 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-2020:4086