Ask Your Question
0

cloud-init does not grow the partition nor the filesystem

asked 2014-10-14 05:05:30 -0500

Korni22 gravatar image

I am currenty preparing OpenStack-ready images of CentOS 7 and Ubuntu 14.04.

For the "automation" I use http://www.packer.io/ (packer), which is provided by you with a json-template. Packer then starts the installation using the virtualization you specify (in my case qemu).

After the installation, the virtual machine is being provisioned via SSH by packer and the scripts you supply.

The status:

  • The root disk has 3 GB.
  • One partition, ext4, boot-flag, 100% of the root disk.

What I am trying to achieve here:

  • The image should resize itself on the first start to the max size of the disk

The Problem:

It does not work. It does not matter if I install only cloud-init or cloud-init and cloud-utils or cloud-init and cloud-utils and cloud-utils-growpart. I do not change the default cloud-init config, apart from enabling the root-login via ssh.

My cloud-init config is standard, apart from this line

disable_root: 0

My question is:

  • has someone already done this? I can't seem to find a working example

If you need any additional information, just ask :)

edit retag flag offensive close merge delete

Comments

I had this problem with CentOS 6 and http://blog.backslasher.net/growroot-centos.html (these instructions) were very helpful. It uses dracut-modules-growroot and rebuilds initrd images to grow the partition, then cloud-init and probably resize2fs to grow the filesystem.

fidian gravatar imagefidian ( 2015-12-01 10:38:48 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
1

answered 2014-10-14 08:33:07 -0500

larsks gravatar image

has someone already done this? I can't seem to find a working example

The Centos 7 cloud images appear to work correctly, so that's probably a good place to start. Here's an extract from the log on a successful boot/resize:

helpers.py[DEBUG]: Running config-growpart using lock (<cloudinit.helpers.DummyLock object at 0x32fdc10>)
cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  Using default: {'ignore_growroot_disabled': False, 'mode': 'auto', 'devices': ['/']}
util.py[DEBUG]: Running command ['growpart', '--help'] with allowed return codes [0] (shell=False, capture=True)
util.py[DEBUG]: Reading from /proc/734/mountinfo (quiet=False)
util.py[DEBUG]: Read 2695 bytes from /proc/734/mountinfo
util.py[DEBUG]: Reading from /sys/class/block/vda1/partition (quiet=False)
util.py[DEBUG]: Read 2 bytes from /sys/class/block/vda1/partition
util.py[DEBUG]: Reading from /sys/devices/pci0000:00/0000:00:04.0/virtio1/block/vda/dev (quiet=False)
util.py[DEBUG]: Read 6 bytes from /sys/devices/pci0000:00/0000:00:04.0/virtio1/block/vda/dev
util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)
util.py[DEBUG]: Running command ['growpart', '/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)
util.py[DEBUG]: resize_devices took 0.529 seconds
cc_growpart.py[INFO]: '/' resized: changed (/dev/vda, 1) from 8588886016 to 21466932224
helpers.py[DEBUG]: Running config-resizefs using lock (<cloudinit.helpers.DummyLock object at 0x32fdd50>)
util.py[DEBUG]: Reading from /proc/734/mountinfo (quiet=False)
util.py[DEBUG]: Read 2695 bytes from /proc/734/mountinfo
cc_resizefs.py[DEBUG]: resize_info: dev=/dev/vda1 mnt_point=/ path=/
util.py[DEBUG]: Running command ['running-in-container'] with allowed return codes [0] (shell=False, capture=True)
util.py[DEBUG]: Running command ['lxc-is-container'] with allowed return codes [0] (shell=False, capture=True)
util.py[DEBUG]: Reading from /proc/1/environ (quiet=False)
util.py[DEBUG]: Read 0 bytes from /proc/1/environ
util.py[DEBUG]: Reading from /proc/self/status (quiet=False)
util.py[DEBUG]: Read 1043 bytes from /proc/self/status
cc_resizefs.py[DEBUG]: Resizing / (xfs) using xfs_growfs /dev/vda1
util.py[DEBUG]: Running command ('xfs_growfs', '/dev/vda1') with allowed return codes [0] (shell=False, capture=True)
util.py[DEBUG]: Resizing took 1.187 seconds
cc_resizefs.py[DEBUG]: Resized root filesystem (type=xfs, val=True)

This suggests that in addition to cloud-init, you need to make sure the growpart command is available to resize the partition, and you need an appropriate filesystem grow command (xfs_growfs in this case, otherwise probably resize2fs for ext filesystems).

So, I would check:

  1. Is growpart installed on your system?
  2. Is an appropriate filesystem resize command available?
  3. Are there any errors in your cloud-init logs?
edit flag offensive delete link more

Comments

I am going to build an image with growpart installed and report back tomorrow.

resize2fs is available.

And https://gist.github.com/8665e8efae3959565e8a (here) is a complete bootlog.

Thanks for your help!

Korni22 gravatar imageKorni22 ( 2014-10-14 08:39:03 -0500 )edit

okay, I switched from ext4 to xfs, did not solve the problem, apparently I the problem is that the partition isn't even resized

Korni22 gravatar imageKorni22 ( 2014-10-15 06:13:25 -0500 )edit

growpart is the tool used to resize the partition. As you can see from the above log output, cloud-init logs about tasks it performs. What does your cloud-init log look like? Is it running growpart? Is it generating any errors?

larsks gravatar imagelarsks ( 2014-10-15 12:45:22 -0500 )edit

I just ran into this problem with the default installation of Ubuntu 16.04. I don't think it applies to OP's problem, but others might see this.. Make sure there's not a swap partition blocking the growth of the root partition!

holocron gravatar imageholocron ( 2016-04-07 10:31:23 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2014-10-14 05:05:30 -0500

Seen: 12,705 times

Last updated: Oct 14 '14