In a conversation with cwalters he said:
ok here's the deal, qcow2 is a thin-provisioned disk format, fedora uses 40GB by default for vagrant that's defined here: https://pagure.io/releng/blob/master/f/scripts/build-cloud-images#_68 now where's that 3GB coming from? here: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base-vagrant.ks that includes https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n46 that's outside the VM now inside, cloud-init normally starts and uses "growpart" early on boot except in vagrant, it's disabled because hardcoded ssh keys and stuff so typing: growpart /dev/vda 1 then resize2fs /dev/vda1 i'd say this is really a fedora build system bug - the kickstart should match the qcow2 it's a one liner fix to spin-kickstarts
So while his commands work I couldn't find a way to get them in early enough to solve my disk space usage problems. But something is wrong when vagrant+libvirt images are only 3G and don't auto-grow, for sure.
I ran into this problem, and fortunately these commands worked for me.
Holy wow, you can resize a filesystem while it's mounted these days?! We truly live in the future!
Hey eparis. I think this was an issue for F22 because the --grow line wasn't in the kickstart for F22:
--grow
[root@f22tunir ~]# cat /etc/redhat-release Fedora release 22 (Twenty Two) [root@f22tunir ~]# cat /root/anaconda-ks.cfg | grep -P "^part" part / --fstype="ext4" --size=3000
The part line [1] in the kickstart now properly uses --grow to grow the partition to full disk size. The filesystem for /dev/vda1 is 40G for the most recent F23 nightly [2].
part
So this issue is fixed for F23.
[1] https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n46 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=11093504
Login to comment on this ticket.