investigate a growfs by default

[cgwalters]

Today these projects contain logic to grow the rootfs by default:

• cloud-init
• Ignition (as integrated in fcos and derivatives)
• systemd-repart

There may be others. If one generates an AMI (e.g.) from our generic base image, then the rootfs won't be grown.

Now of course...ideally one can specify the rootfs default size in the container (e.g. instead of dynamically choosing 100G at instance creation time, I can write a partitioning config in the container). See containers/bootc#287

But...a lot of users are probably going to try just deploying our stock base image as an AMI generated via bib, which hardcodes 10G right now. (see above issue for some discussion)

It looks to me like systemd-repart doesn't directly support this (its Type=root seems to want to dispatch via the discoverable partitions spec, but we can't rely on that), but I can't imagine it'd be too hard to add. I think conceptually cloud-init would be OK if we grew the rootfs before it did.

[cgwalters]

#397 will help, but won't be on by default.

My inclination then is to close this by documenting the usage of a simple systemd unit that executes growpart on the root.

[cgwalters]

Someone also floated the idea that we use LVM by default; if we do that it'd change things here; in some ways it'd be simpler. (There's also stratis, etc.)

[jlebon]

One thing is growpart doesn't grow the filesystem. Hmm, if we really wanted, we could probably lift ignition-ostree-growfs.sh out of f-c-c, clean it up, and share it somehow. Though it's begging to be rewritten in a proper language (if we do that, we could propose adding it to cloud-utils directly).

[cgwalters]

There's a big difference here which is that code is designed to run in the initramfs, whereas traditionally cloud-init's growpart runs in the real root (though I bet it could run from the initramfs). And this gets into the fact that we don't ship the filesystem tools in the initramfs in this base image because it's designed to either be installed "dynamically" (e.g. bootc install/anaconda that make filesystems on the target system), or bib but that should be tuning the filesystem choices again based on input osbuild/bootc-image-builder#52

The rootfs growing is really for generic cloud images, and so...the more I think about it, the root problem here is really what bib is doing linked from that above issue.

Adding growpart just gives us that baseline tool as an out for a broken situation.

(Anyone can feel free to reopen if you disagree of course)

[cgwalters]

We went back and forth on this and decided for now to try to add growpart to the base, but that dropped off the radar. It's...just very messy.

[fabiendupont]

What about have a systemd unit in the initrd that grows the boot the root partition (growpart) and the root filesystem (growfs) before it is mounted, so that it takes the whole install disk? This could be an optional setting controlled by a kernel argument.

[cgwalters]

https://gitlab.com/fedora/bootc/base-images/-/merge_requests/9