After taking a second look, it appears that with btrfs, if I run
root@test-mongo:~# btrfs filesystem resize max /
Resize device id 1 (/dev/sda2) from 3.90GiB to max
the rest of the 25GiB appear. Is there a way to bake this right into the image without just piling on the first-start systemd unit or using something like cloud-init?
Also, how do I select to create a slim “cloud-only” image, instead of a fat image with everything?
I am currently running incus 1:6.11-debian12-202504032034.
If you include cloud-init in your custom VM image, then it should handle the resize for you, at least it does for ext4.
Otherwise, you may need to ship a systemd unit similar to our incus-growpart.service which will handle the growpart+btrfs resize on boot.
The fact that your partition was the correct size here suggests that incus-growpart is in your image, it just failed to do the resize2fs as it’s not on ext4.
If you used distrobuilder directly to produce that image, you could contribute to distrobuilder to template the incus-growpart.service unit so it runs the correct command based on the filesystem selected.
As for what makes it into the image, it really depends on how you build it. If that was done using distrobuilder, then you can tweak the YAML with whatever you want in there, though our images are pretty minimal to begin with.
Thank you! I’ll see what I can do there. I dimly remember that there was a growfs or so error message on boot. As for cloud images vs. “normal” images, I think I once had a cloud image at around 130MB, whereas the normal image is somewhere between 300 and 400MB. Especially if you have a slow network, this makes a difference.
I didn’t like my previous patch too much, so here’s another one that works without an external script, but one needs to tolerate that one of the units will fail: