Allow rootfs optionally >10G in images

[mtalexan]

Feature Request

Support image rootfs >10G.

Currently the size of the rootfs partition in images is set when supermin is generating it during the runvm() function in src/cmdlib.sh. This is hardcoded to 10G.
Customized builds that add more packages or files can easily end up with an ostree >10G.

Desired Feature

Support rootfs of images >10G, possibly a configurable size.

Example Usage

If many files or large files are added as additional RPMs, populated via overlays, added as overrides, or eventually included somehow as physically-bound container images, the final ostree commit easily ends up exceeding 10G.

Other Information

While ideally it should probably be a key in the image.yaml file to set this or the ostree on-disk size should be calculated and used with some additional buffer size, a much simpler solution is to add a COSA_SUPERMIN_SIZE optional environment variable that defaults to the current 10G but can be set by the caller. This is consistent with the already existing COSA_SUPERMIN_MEMORY optional environment variable used in the same code to set the memory for the kola qemuexec call on the supermin-generated output.

While seemingly related, the image.yaml size: key sets the max size of the dynamically allocated qcow2 virtual disk image. But the content in the qcow2 virtual disk image is created by running supermin to generate an initrd, kernel, and rootfs, and then inserting those into the qcow2 virtual disk as partitions. The existing logic that adds these to the qcow2 image already seems to support dynamically determining how big the rootfs is by looking at the supermin-generated rootfs file. So the only problem is that we specify a hardcoded 10G to the supermin command for the size of the rootfs to create before we proceed to put the ostree in it.

[mtalexan]

I was finally filing some PRs from my older private fork, and this was one of the issues I had encountered and fixed.

---

Looking at more recent changes, it looks like the entire runvm() function is being deprecated. Builds from osbuild seem to use the entirely separate runvm-osbuild stand-alone script now instead, which does dynamic ostree size calculation. So this is a problem in the direct call code only, and not in osbuild triggered builds.

[mtalexan]

From #3956 (comment)

This was a bug on a historical version of coreos-assembler that has since been fixed. In summary, the ${workdir}/cache within the supermin VM needs to be big enough for the entire ostree to fit in it while the output image is being generated from it. In the historical code this path was part of the supermin rootfs itself because the (deleted) create_disk.sh that generated the image was called with runvm(), but now the osbuild tool that generates the image is called with runvm_with_cache_snapshot() that creates a separate qcow2 file that's automatically mounted over the ${workdir}/cache, has a default size of 30G, and is already configurable with the RUNVM_CACHE_SIZE environment variable.