It looks like this logic in base/stagebase.py makes a bad assumption: if src == "tmpfs": if "var_tmpfs_portage" in self.settings: _cmd = ['mount', '-t', 'tmpfs', '-o', 'size=' + self.settings['var_tmpfs_portage'] + 'G', src, target] else: _cmd = ['mount', '-t', 'tmpfs', src, target] else: It checks to see if "var_tmpfs_portage" was defined in /etc/catalyst/catalyst.conf, and if so, uses the specified size for a tmpfs bind mount for /var/tmp/portage. But if that settings is not defined, catalyst creates a default-sized tmpfs bind mount anyways. I assume on modern systems that this is not a problem, especially when there is RAM aplenty, as Linux will default to 50% of RAM for the tmpfs size. But my build system, an old SGI Octane, has 2GB of RAM. Putting the portage TMPDIR into a ramdrive is not viable, because the machine will give 1GB to the tmpfs and keep the other 1GB as RAM. When dealing with large builds, this will fail with an error that there is no space left on the device. If "var_tmpfs_portage" is undefined, catalyst should take that to mean that it should *not* mount a tmpfs for PORTAGE_TMPDIR at all.
This was just being discussed a few days ago, and is probably fixed here: https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=8441372c285726de85c71a83035a9e11cc47f037
(In reply to Ben Kohler from comment #1) > This was just being discussed a few days ago, and is probably fixed here: > https://gitweb.gentoo.org/proj/catalyst.git/commit/ > ?id=8441372c285726de85c71a83035a9e11cc47f037 I suggest we can close this when new release gets tagged?
Had to wait for a stage2 attempt finished before I could test the patch. Testing it now on a stage3. If it works, unpacking the distfile of a known large package shouldn't fail (e.g., something like binutils or gcc).
(In reply to Joshua Kinard from comment #3) > Had to wait for a stage2 attempt finished before I could test the patch. > Testing it now on a stage3. If it works, unpacking the distfile of a known > large package shouldn't fail (e.g., something like binutils or gcc). It looks like commit 8441372c2857 fixes the issue. Feel free to resolve as FIXED. Thanks!
