@Ben,

I'm seeing a ~100% repro of this bug on the current 16.04 image in Azure on VM resize. Create a D2_v2 VM, check that fstab has /dev/disk/cloud/azure_resource-part1 on /mnt and that /mnt is mounted as ext4. In that case, provisioning went correctly. Now after resizing this VM, e.g. to a D1_v2, /mnt will be mounted as fuseblk with NTFS as the underlying filesystem. The relevant logs from cloud-init:

Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: Creating new filesystem.
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: Checking /dev/sdb against default devices
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: Manual request of partition 1 for /dev/sdb1
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: Checking device /dev/sdb1
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] util.py[DEBUG]: Running command ['/sbin/blkid', '-c', '/dev/null', '/dev/sdb1'] with allowed return codes [0, 2] (shell=False, capture=True)
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: Device /dev/sdb1 has Temporary Storage ntfs
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: Device /dev/sdb1 is cleared for formating
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: File system None will be created on /dev/sdb1
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] util.py[DEBUG]: Running command ['/bin/lsblk', '--pairs', '--output', 'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', '--nodeps'] with allowed return codes [0] (shell=False, capture=True)
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]: Creating file system None on /dev/sdb1
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] cc_disk_setup.py[DEBUG]:      Using cmd: /sbin/mkfs.ext4 /dev/sdb1
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdb1'] with allowed return codes [0] (shell=False, capture=True)
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: [CLOUDINIT] util.py[DEBUG]: Creating fs for /dev/disk/cloud/azure_resource took 0.038 seconds
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Cloud-init v. 0.7.7 running 'modules:config' at Thu, 04 Aug 2016 18:19:38 +0000. Up 18.80 seconds.
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: 2016-08-04 18:19:38,478 - util.py[WARNING]: Failed during filesystem operation
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Failed to exec of '['/sbin/mkfs.ext4', '/dev/sdb1']':
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Unexpected error while running command.
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Command: ['/sbin/mkfs.ext4', '/dev/sdb1']
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Exit code: 1
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Reason: -
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Stdout: ''
Aug 04 18:19:38 linuxvm-5 cloud-init[2629]: Stderr: 'mke2fs 1.42.13 (17-May-2015)\n/dev/sdb1 is mounted; will not make a filesystem here!\n'

The mnt.mount systemd unit was started before cloud-config.service was started, but that looks by design, looking at the declared dependencies/ordeing in systemd config (cloud-config.service -> cloud-config.target -> cloud-init-local.service -> local-fs.target -> *.mount).

I can open a new bug, but this looks like a regression of this one. Let me know if you want me to open a new one instead.

Thanks, Paul