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

Discussion:

sylecn

2014-08-06 02:35:01 UTC

Hi stackers,

I have come across this problem of growpart/resizefs not working with
CentOS 6.5 Cloud image on first boot.

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

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.

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)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140806/4a4c42be/attachment.html>

Juerg Haefliger

2014-08-06 06:05:03 UTC

Permalink

Hi,

Post by sylecn
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?

Post by sylecn
Here is the relevant config in cloud.cfg
==============================
mode: auto
devices: ["/"]
resize_rootfs: True
resize_rootfs_tmp: /dev
- 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.

Post by sylecn
============================
[CLOUDINIT] helpers.py[DEBUG]: Running config-growpart using lock

(<cloudinit.helpers.DummyLock object at 0x1ed06d0>)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--help'] with

allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Reading from /proc/1108/mountinfo

(quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 521 bytes from /proc/1108/mountinfo
[CLOUDINIT] util.py[DEBUG]: Reading from /sys/class/block/vda1/partition

(quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 2 bytes from

/sys/class/block/vda1/partition

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Reading from

/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda/dev (quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 6 bytes from

/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda/dev

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--dry-run',

'/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '/dev/vda', '1']

with allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: resize_devices took 0.076 seconds
[CLOUDINIT] cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary

(/dev/vda, 1)

Post by sylecn
[CLOUDINIT] helpers.py[DEBUG]: Running config-resizefs using lock

(<cloudinit.helpers.DummyLock object at 0x1ed08d0>)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Reading from /proc/1108/mountinfo

(quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 521 bytes from /proc/1108/mountinfo
[CLOUDINIT] cc_resizefs.py[DEBUG]: resize_info: dev=/dev/vda1 mnt_point=/

path=/

Post by sylecn
[CLOUDINIT] cc_resizefs.py[DEBUG]: Resizing / (ext4) using resize2fs

/dev/vda1

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ('resize2fs', '/dev/vda1')

with allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[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.

Post by sylecn
===================================
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

Post by sylecn
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

Post by sylecn
--
Thanks,
Yuanle
_______________________________________________

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Post by sylecn
Post to : openstack at lists.openstack.org

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>

sylecn

2014-08-06 07:11:10 UTC

Permalink

Post by sylecn
Hi,

Post by sylecn
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?

Post by sylecn
============================
[CLOUDINIT] helpers.py[DEBUG]: Running config-growpart using lock

(<cloudinit.helpers.DummyLock object at 0x1ed06d0>)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--help'] with

allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Reading from /proc/1108/mountinfo

(quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 521 bytes from /proc/1108/mountinfo
[CLOUDINIT] util.py[DEBUG]: Reading from /sys/class/block/vda1/partition

(quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 2 bytes from

/sys/class/block/vda1/partition

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Reading from

/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda/dev (quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 6 bytes from

/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda/dev

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--dry-run',

'/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '/dev/vda',

'1'] with allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: resize_devices took 0.076 seconds
[CLOUDINIT] cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary

(/dev/vda, 1)

Post by sylecn
[CLOUDINIT] helpers.py[DEBUG]: Running config-resizefs using lock

(<cloudinit.helpers.DummyLock object at 0x1ed08d0>)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Reading from /proc/1108/mountinfo

(quiet=False)

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Read 521 bytes from /proc/1108/mountinfo
[CLOUDINIT] cc_resizefs.py[DEBUG]: resize_info: dev=/dev/vda1

mnt_point=/ path=/

Post by sylecn
[CLOUDINIT] cc_resizefs.py[DEBUG]: Resizing / (ext4) using resize2fs

/dev/vda1

Post by sylecn
[CLOUDINIT] util.py[DEBUG]: Running command ('resize2fs', '/dev/vda1')

with allowed return codes [0] (shell=False, capture=True)

Post by sylecn
[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.

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

I didn't know about initrd based growpart. I see both cloud-utils-growpart
and dracut-modules-growroot are installed in the base image (via yum info).
Do I need any config on kernel modules or build a special initrd to make
growpart work on first boot?
I didn't see growpart message in dmesg and kernel syslog (/var/log/messages
on the guest) in first boot and 2nd boot.
/var/log/boot.log also has no information on that. Where can I get the boot
message from initrd growpart?

guest kernel: 2.6.32-431.3.1.el6.x86_64

package version:
Installed Packages
Name : cloud-utils-growpart
Arch : x86_64
Version : 0.27
Release : 10.el6
Size : 53 k
Repo : installed

Post by sylecn
From repo : epel

Summary : Script for growing a partition
URL :
https://launchpad.net/cloud-utils/trunk/0.27/+download/cloud-utils-0.27.tar.gz
License : GPLv3
Description : This package provides the growpart script for growing a
partition. It is
: primarily used in cloud images in conjunction with the
dracut-modules-growroot
: package to grow the root partition on first boot.

Name : dracut-modules-growroot
Arch : noarch
Version : 0.20
Release : 2.el6
Size : 43 k
Repo : installed

Post by sylecn
From repo : epel

Summary : Automatically resize the root partition on first boot
URL :
https://launchpad.net/ubuntu/saucy/+source/cloud-initramfs-tools/0.20ubuntu1/+files/cloud-initramfs-tools_0.20ubuntu1.tar.gz
License : GPLv3
Description : This dracut module will re-write the partition table of a
disk so that the
: root partition has as much space as possible, bumping it up
to the edge of the
: disk, or the edge of the next partition.

growpart and resize still happens on 2nd boot, not first boot.
--
*YY Inc. is hiring* openstack and python developers. Interested? Check
http://soa.game.yy.com/jobs.html

--
Thanks,
Yuanle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140806/1ce26c14/attachment.html>

Juerg Haefliger

2014-08-06 11:08:18 UTC