#120 Fedora 22 Cloud vagrant image does not extend filesystem to disk size
Closed None Opened 8 years ago by pwnall.

Copied from RHBZ #1260800, based on responses seen on other bugs related to the Vagrant image.

Description of problem:

The Vagrant image for Fedora 22 cloud does not extend the filesystem to fill up the entire disk.

Version-Release number of selected component (if applicable):
https://download.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_64/Images/Fedora-Cloud-Base-Vagrant-22-20150521.x86_64.vagrant-virtualbox.box

How reproducible:
Always

Steps to Reproduce:
1. Set up a new Vagrant box using the Fedora 22 cloud base box.
2. vagrant ssh
3. Inspect the partition table.

Actual results:

[vagrant@localhost ~]$ sudo fdisk -l /dev/sda
Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe02b2711

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 6146047 6144000 3G 83 Linux

Expected results:

I'd expect to see the filesystem grown to fill the virtual disk.

Additional info:

This is a serious obstacle to deploying Fedora Cloud for me. I need to be able to test things out in a Vagrant box before pushing things out to production. The 3G filesystem makes it impossible for me to load everything I need into the VM.

Please let me know if there is any other information I can provide to help narrow this down.


This seems to be the same as https://fedorahosted.org/cloud/ticket/109

While I'm commenting I'll go ahead and add that the version of vagrant-libvirt in Fedora 22 doesn't have the "machine_virtual_size", which I would consider to be part of the full solution. (I believe 0.0.30 has it.)

I was wrong, vagrant-libvirt 0.0.31 was just tagged, which contains the machine_virtual_size option.

hey jpeeler.. so it sounds like with F23 everything will working. Do you agree? If so I'll go ahead and close this.

In the mean time do you have steps to workaround this? This works:

growpart --dry-run /dev/vda 1 && growpart /dev/vda 1 && resize2fs /dev/vda1

As long as vagrant-libvirt gets rebased the first part of the problem will be solved. But I considered this ticket to include automatic resizing of the image rather than doing manually as you indicated. I personally was more interested in the atomic image, but both are important. Here's what I've been doing for the centos atomic image:

config.vm.provision :shell, inline: <<-SHELL
growpart /dev/vda 2
pvresize /dev/vda2
lvresize -l +100%FREE /dev/atomicos/docker-pool
SHELL

I suspect usage of cloud-init is the key to automating, but the centos atomic image doesn't have cloud-init (fedora does though it seems, hrm). Finally, there are instructions to add a new disk (http://www.projectatomic.io/docs/quickstart/), but I prefer to just resize as that is a lot more automatable.

Replying to [comment:4 jpeeler]:

I suspect usage of cloud-init is the key to automating, but the centos atomic image doesn't have cloud-init (fedora does though it seems, hrm). Finally, there are instructions to add a new disk (http://www.projectatomic.io/docs/quickstart/), but I prefer to just resize as that is a lot more automatable.

jpeeler, centos atomic has cloud-init.

Ah good! You're right - I checked the wrong image. I'm sure cloud-init can be used here to do this somehow, right?

I'm sure it could: http://cloudinit.readthedocs.org/en/latest/topics/examples.html -- there are ways to run arbitrary commands in there.

I've been using the add a second disk method, with a vagrantfile like this: https://gist.github.com/jasonbrooks/b84117ada0ec1f7dab61, although, that one is for plain centos, and includes some lines not needed for atomic.

I'd like to see us have an automatically resizing base disk, though, w/ something like this new vagrant-libvirt option.

I'm not sure I understand.. You shouldn't have to use cloud-init at all. The images from F22 Cloud base vagrant image was broken because the root fs didn't extend to the full 40G. The F23 cloud base vagrant image has been fixed so that it will use the whole 40G by default. You won't need to extend the partition/fs at all unless 40G isn't enough.

Cloud-init usage allows automatic dynamic resizing and might be the best option to allow vagrant to nicely mirror what happens with most cloud images. The F22 vagrant image wasn't technically broken, it was just small at 3G. I would say that the situation with a static 40G image is only slightly better now, because if somebody wants a smaller image they'll have to umount the filesystem since (I think) online resizing only works for growing the size. And again, if somebody wants something larger than 40GB they'll have to resize the filesystems/partitions themselves as well. Hope that's clear - the whole point is to properly utilize the newly available "machine_virtual_size" option in vagrant-libvirt.

Closing this ticket as part of trac clean up process. If you want to reopen, please reopen it after we move to pagure.io as atomic-wg.

Login to comment on this ticket.

Metadata