Comment 16 for bug 1611074

At the moment, I'm hoping the issue really stems from this being an upgrade, and that a new instance that already had the newer version would be OK. What I believe is happening is:
 a.) old cloud-init on first boot writes /etc/fstab for the resource disk with something like:
     /dev/disk/cloud/azure_resource-part1 /mnt auto defaults,nofail,comment=cloudconfig 0 2
 b.) apt-get install of new cloud-init
 c.) resize
 d.) new system boots with the /etc/fstab line show above. The fstab entry does not stop systemd from mounting the device, and the mount of the ntfs partition happens. cloud-init goes to format it, and mkfs.ext4 complains.

The new cloud-init writes an fstab entry with the options field as:
 defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig

I see some other paths that i'd like to clean up, including grabbing Daniel's merge proposal at [1], but I'm currently hopeful that the issue above is what we're seeing.

We can test that theory by manually editing the /etc/fstab entry after first boot to include the options field above (specifically x-systemd.requires=cloud-init.service).

--
[1] https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/310411