[Openstack] CentOS 6.5 cloud-init growpart/resizefs does not work on first boot.

Juerg Haefliger juergh at gmail.com
Wed Aug 6 06:05:03 UTC 2014


Hi,


On Wed, Aug 6, 2014 at 4:35 AM, sylecn <sylecn at gmail.com> wrote:
>
> Hi stackers,
>
> I have come across this problem of growpart/resizefs not working with
CentOS 6.5 Cloud image on first boot.

Which kernel version are you running in the guest?


> Here is the relevant config in cloud.cfg
> ==============================
>
> growpart:
>   mode: auto
>   devices: ["/"]
> resize_rootfs: True
> resize_rootfs_tmp: /dev
>
> cloud_init_modules:
>  - bootcmd
>  - write-files
>  - growpart
>  - resizefs

Growpart called by cloud-init only works for kernels >3.8. Only newer
kernels support changing the partition size of a mounted partition. When
using an older kernel the resizing of the root partition happens in the
initrd stage before the root partition is mounted and the subsequent
cloud-init growpart run is a no-op.


> Here is the relevant log on first boot:
> ============================
> [CLOUDINIT] helpers.py[DEBUG]: Running config-growpart using lock
(<cloudinit.helpers.DummyLock object at 0x1ed06d0>)
> [CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--help'] with
allowed return codes [0] (shell=False, capture=True)
> [CLOUDINIT] util.py[DEBUG]: Reading from /proc/1108/mountinfo
(quiet=False)
> [CLOUDINIT] util.py[DEBUG]: Read 521 bytes from /proc/1108/mountinfo
> [CLOUDINIT] util.py[DEBUG]: Reading from /sys/class/block/vda1/partition
(quiet=False)
> [CLOUDINIT] util.py[DEBUG]: Read 2 bytes from
/sys/class/block/vda1/partition
> [CLOUDINIT] util.py[DEBUG]: Reading from
/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda/dev (quiet=False)
> [CLOUDINIT] util.py[DEBUG]: Read 6 bytes from
/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda/dev
> [CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--dry-run',
'/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)
> [CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '/dev/vda', '1']
with allowed return codes [0] (shell=False, capture=True)
> [CLOUDINIT] util.py[DEBUG]: resize_devices took 0.076 seconds
> [CLOUDINIT] cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary
(/dev/vda, 1)
> [CLOUDINIT] helpers.py[DEBUG]: Running config-resizefs using lock
(<cloudinit.helpers.DummyLock object at 0x1ed08d0>)
> [CLOUDINIT] util.py[DEBUG]: Reading from /proc/1108/mountinfo
(quiet=False)
> [CLOUDINIT] util.py[DEBUG]: Read 521 bytes from /proc/1108/mountinfo
> [CLOUDINIT] cc_resizefs.py[DEBUG]: resize_info: dev=/dev/vda1 mnt_point=/
path=/
> [CLOUDINIT] cc_resizefs.py[DEBUG]: Resizing / (ext4) using resize2fs
/dev/vda1
> [CLOUDINIT] util.py[DEBUG]: Running command ('resize2fs', '/dev/vda1')
with allowed return codes [0] (shell=False, capture=True)
> [CLOUDINIT] util.py[DEBUG]: Resizing took 0.004 seconds
>
> In the base image, I have upgraded cloud-init to 0.7.4-1.el6, and
installed cloud-utils, cloud-initramfs-tools. After the first *reboot*,
growpart/resizefs does their job and the root file system is grown to disk
size.

There is no cloud-initramfs-tools package for CentOS. You need
cloud-utils-growpart and dracut-modules-growroot from EPEL6 for the initrd
based partition resizing.


> After a reboot, the relevant cloud-init logs:
> ===================================
> cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/vda, 1)
> util.py[DEBUG]: Resizing took 13.776 seconds
> cc_resizefs.py[DEBUG]: Resized root filesystem (type=ext4, val=True)

These are log messages from cloud-init's growpart run. Can you post the
boot messages from initrd growpart?


...Juerg



> I wish the growpart/resizefs happen on first boot, what can I do?
>
>
> --
> YY Inc. is hiring openstack and python developers. Interested? Check
http://soa.game.yy.com/jobs.html
>
> --
> Thanks,
> Yuanle
>
> _______________________________________________
> Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140806/72391807/attachment.html>


More information about the Openstack mailing list