Version 2.408.65 of livecd-rootfs has fixed this issue.
Test case:
Built a box with the version of livecd-rootfs
vagrant box add build.output/livecd.ubuntu-cpc.vagrant.box --name xenial-test
vagrant init xenial-test
vagrant up
vagrant ssh default
Run `df -H` inside the vagrant box
Observe Disk size of drive mounted at / and observe that the disk is ~ 40G
To confirm that this won't break users upgrading to this box, but with < 40G disks, I checked the size of the VMDK backing the box. It was listed at 1.1G. I created a 15G file with `dd if=/dev/urandom of=filename bs=1024 count=15M` I was able to observe the VMDK growing by 15G.
So if a user were to have a 10G box fully allocated, and then upgrade to the new box built with the latest version of livecd-rootfs, the user would not be impacted until they tried to fill up the 40G.
Version 2.408.65 of livecd-rootfs has fixed this issue.
Test case:
Built a box with the version of livecd-rootfs
vagrant box add build.output/ livecd. ubuntu- cpc.vagrant. box --name xenial-test
vagrant init xenial-test
vagrant up
vagrant ssh default
Run `df -H` inside the vagrant box
Observe Disk size of drive mounted at / and observe that the disk is ~ 40G
To confirm that this won't break users upgrading to this box, but with < 40G disks, I checked the size of the VMDK backing the box. It was listed at 1.1G. I created a 15G file with `dd if=/dev/urandom of=filename bs=1024 count=15M` I was able to observe the VMDK growing by 15G.
So if a user were to have a 10G box fully allocated, and then upgrade to the new box built with the latest version of livecd-rootfs, the user would not be impacted until they tried to fill up the 40G.