Open robbycuenot opened 6 months ago
I think the issue here is probably that the live setup isn't "swap-aware". It sizes the ephemeral rootfs based on physical RAM (more specifically, the size=50%
tmpfs mount option is documented as being relative to available physical RAM). But anyway, another thing here is that this code executes well before Ignition would create the swap device. (Note BTW that nowadays you can use .storage.filesystems[]
for formatting the swap device too.)
The solutions I am considering in the meantime involve creating a filesystem on the swap drive specifically for
/var
That's what I'd suggest as well. If you want no persistence/caching at all, you can always have Ignition wipe and re-mkfs
each time.
Another approach is to manually do the same XFS loopback on tmpfs trick on top of /var/lib/containers
.
Another approach is to manually do the same XFS loopback on tmpfs trick on top of
/var/lib/containers
.
I need to familiarize myself with how this process works, but it sounds like a potential solution :)
Describe the bug
I am pxe booting FCOS 39 with UEFI and SecureBoot using shim.efi -> grubx64.efi on bare-metal (both virtualized and on real hardware, Dell Optiplex 7060 Micro with 8GB DDR4). In both scenarios, a 256GB drive is added as swap space. The goal is to have stateless machines running containers, using ignition.
Regardless of memory available to the system, running containers in such an environment results in inode exhaustion over time:
By default, podman containers are stored under /var, which is stored under the /dev/loop0 filesystem.
The solutions I am considering in the meantime involve creating a filesystem on the swap drive specifically for /var; however I am curious if there is a way to fix this for systems that do not have physical storage attached but do have ample memory.
For reference, I am creating 3 containers at startup -- a terraform cloud agent, a github actions runner, and a fan controller for another machine.
Reproduction steps
Expected behavior
Containers are able to be created until memory exhaustion is reached.
Actual behavior
Containers fail prematurely, due to an inability to write new files to the overlayfs, despite several GB of free memory on the system.
System details
Butane or Ignition config
Additional information
No response