Filesystem not being resized

[Harm Weites]

Upon booting a new instance of Cirros 0.3.1, 0.3.2-pre1 or 0.3.2-pre2 the resize2fs command isn't run. Growroot did run, it's just the filesystem that isn't resized. This instance is booting from a volume, the platform is Openstack.

GROWROOT: CHANGED: partition=1 start=16065 old: size=64260 end=80325 new: size=6265350,end=6281415

And after reboot:
NOCHANGE: partition 1 is size 6265350. it cannot be grown

So partitions look to be just fine.

Cirros-per should have put down a marker in /var/lib/cirros/sem but for some reason that didn't happen. Hacking a -v into /etc/rc3.d/S55-resizefs shows it does try to run resize2fs:

using state_dir=/var/lib/cirros/sem, marker=once.once.resizefs
[once] sh -c o=/tmp/resize.out;

So somewhere along these lines it bails out:
cirros-per once resizefs -- \
                        sh -c 'o=/tmp/resize.out;
                                resize2fs -d 30 /dev/root >$o 2>&1 &&
                                rm -f $o && exit 0 ||
                                echo "resize failed!" 1>&2;
                                cat $o 1>&2; exit 1;' resizefs &

Contents of /tmp/resize.out only show the following:
resize2fs 1.42.2 (27-Mar-2012)

Manually running resize2fs does bring me a fullsized filesystem - but thats not a solution.

[Scott Moser (smoser)]

Ok, some things I've tried in an effort to debug this:
 * changed 'resize2fs' to 'sleep 30'.
    The sleep gets killed all the same.
 * moved the content of the 'sh -c' into a separate program 'resize-root' in /bin and invoke it from there.
   This also failed to do anything.

The one thing that *does* seem to fix it is removing the '&'.

The thing I'm suspecting right now is that when /etc/init.d/rc.sysinit exits its taking down all its child processes.
It obviously doesn't take down them *all* as dropbear ssh is still running.
dropbear is started with 'start-stop-daemon', so I've wanted to investigate using that for the resize2fs.

Other comments:
 * resize2fs is horrid slow here. When we go from the ~50M file system that is on the disk1.img to the 2G of an 'm1.small', this takes quite some time. The reason I backgrounded was that I didn't want user-data to be blocked on this having finished. Ie, that would effectively make "boot to user-data" on cirros take *much* longer than it does otherwise. maybe 30 seconds in kvm rather than 4, or something on that order.
 * we could make this configurable (and even the backgrounding configurable) via user-data, but atthis point cirros doesn't have any "config" style user-data. only '#!' style.

 * resize2fs on cirros reports 1.42.2 . bug 1179610 tracked a order of magnitude (even up to 100x) improvement in resizefs. The debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663237 reports that as being fixed in 1.42.2-1. The short summary here is that something may allow us to get this resize down to acceptable speeds to not background. There may other options enabled in the resize2fs build that could change performance for size. I'm not sure.

[Scott Moser (smoser)]

fixed in revision 293.

[Harm Weites (harmw)]

I can confirm the fix from r293 does the job, though it takes quite long to complete wich is contrary to what cirros aims at: lightspeed boot times :)

[Scott Moser (smoser)]

fix released in 0.3.2