Comment 1 for bug 1261710

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.