cloud-image VM causes kernel panic if image is resized

This is really interesting.
Its easily reproducible with:
 wget wget http://cloud-images.ubuntu.com/quantal/current/quantal-server-cloudimg-amd64-disk1.img -O disk.img
 qemu-img resize disk.img 20G
 kvm -serial none -drive file=disk.img,if=virtio -curses -m 256

The problem is "fixed", if you remove '-serial none' from the kvm cmdline, and thus get the default serial device that kvm appends.

The original test.xml can be fixed in a similar manner by simply adding:
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>

It can also be fixed by mounting the image and removing 'console=ttyS0' from the kernel command lines in /boot/grub/grub.cfg.

Its hard to see, because observing it makes it work. But, I suspect that the root of the problem is that cloud-initramfs-growpart is writing to stdout, which is redirected to /dev/console, and /dev/console writes are going to the non-existant device 'ttyS0' (as told to by the command line).

Those writes are failing, and something is then leaving the disk in a bad state.

I'm going to mark this 'low', as the work around is easy: attach a serial device.

It seems to me that 'echo hi mom' from the initramfs (or from an upstart job with 'output console') should never result in failure. This is failing in the above situation because the kernel cmdline has 'console=tty1 console=ttyS0' on it, but ttyS0 is not a valid device.
So, it seems the following are potential fixes to the issue:
 a.) kernel doing better sanity checking on console= argument and not attaching /dev/console to something that is going to fail
 b.) initramfs and upstart verifying that /dev/console can be written to, and if not, then redirecting output to somewhere that *is* writable (possibly /run/ or /dev/null).

Clearly, i could change cloud-initramfs-growroot to not fail when it fails to write to its stdout, but that seems not a general fix.

For initramfs, we could do something very early in the initramfs like this:

if ! echo "initramfs running" > /dev/console; then
  read cmdline < /proc/cmdline
  consoles=""
  for tok in $cmdline; do
    [ ${tok#console=} != ${tok} ] || continue;
    tok=${tok#console=}; tok=${tok%,*};
    # reverse order on cmdline
    consoles="$tok $consoles";
  done
  failed=""
  found=""
  for console in $consoles; do
    dev="/dev/${console#/dev}"
    echo "initramfs running" > "$dev" &&
      found=$dev && break ||
      failed="${failed:+${failed}$dev}"
  done
  if [ -n "$found" ]; then
    exec > "$found" 2>&1
  else
    exec > "/run/initramfs.log" 2>&1
  fi
  echo "WARN: Failed write to /dev/console${failed:+ and ${failed}}"
fi

Oh, and there is more information on bug 1061977, where I attempted to do 'a' as a solution, or find a way to re-assign /dev/console from user-space.

above, it seems it'd make good sense to write the warning to /dev/kmsg also.

I'm adding a email thread that I had with smb, apw, and slangasek.
It discusses the issue and potential solutions in some detail.

I'm going to mark this 'wont fix' in cloud-initramfs-tools.
and take away cloud-init.