Bug#989462: set Vagrant box filesystem size to something much larger than 20GB
The Vagrant guidelines say:
"you should create a dynamically resizing drive with a large maximum
size. This causes the actual footprint of the drive to be small
initially, but to dynamically grow towards the max size as disk space is
needed, providing the most flexibility for the end user."
Both VirtualBox and libvirt qcow2 formats support exactly that. The
official Debian box seems to be set at a fixed 20GB. This makes it very
difficult for F-Droid to use these images as the base box for our
F-Droid's base box has been using 1TB for a long time with good results.
Once this is fixed in Debian's images, then F-Droid no longer needs the
forked base box and can use only Debian's.
Thanks for your interest for the Debian Vagrant base boxes. Please note
that these boxes do not have the "official" status, because they're not
built on a Debian Server, but the code to create those boxes is
maintained by Debian Developers.
Now to go back to your initial bug report, creating a thin-provisioned
image seems like a good idea but there is some work involved.
Right now we're building a raw disk image which we are then converting
to qcow2 and vmdk.
My understanding is that creating a thin provisioned disk image would
only work if we're already using a disk image format supporting at the
file system creation step.
maybe @Thomas can comment on that
An alternative would be to use in the disk image the cloud-init rppt
growfs stiff, where you can enlarge the disk via qemu-img, and on the
next boot a script in initrd detect the disk change and resize the
IMHO the second option is the best, as the first option would mean we
would need two different builds, one for VMDK, one for qcows2.
Hans-Christoph, a first question, are you sure VirtualBox supports
dynamically resized drives for VMDK ? Last time I checked it was only VDI.