Hi Dan, Thanks for checking this out. Basically just create a 16.04 VM and resize it (e.g. from D1 to D2). Look at mount/blkid ouput in between and after to see the difference: azure config mode arm azure vm quick-create bug1611074 reprovm centralus linux Canonical:UbuntuServer:16.04.0-LTS:latest $USER -M ~/.ssh/id_rsa.pub -z Standard_D1 ssh to machine, `mount|grep '/dev/sd'` should show something like this: /dev/sda1 on / type ext4 (rw,relatime,discard,data=ordered) /dev/sdb1 on /mnt type ext4 (rw,relatime,data=ordered) Now, resize VM, which forces re-creation of the resource disk (formatted NTFS) azure vm set bug1611074 reprovm -z Standard_D2 ssh to machine, `mount|grep '/dev/sd'` now shows this: /dev/sda1 on / type ext4 (rw,relatime,discard,data=ordered) /dev/sdb1 on /mnt type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096) And `blkid` will show /dev/sda1: LABEL="cloudimg-rootfs" UUID="b2e47a31-37fe-4914-b333-bd1c2a2dacae" TYPE="ext4" PARTUUID="c74ad4d8-01" /dev/sdb1: LABEL="Temporary Storage" UUID="B82692572692170A" TYPE="ntfs" PARTUUID="4041cb24-01" There's a slight chance that it doesn't repro, I noticed that there's a race between the scsi initialization or udev and the code in cloud-init that determines whether it should take /dev/disk/azure/resource or /dev/disk/azure/resource-part1. This code checks for the existence of the latter and if it exists, uses that. Sometimes this check fails, which leads to the resource disk not being prepared or mounted properly. The incorrect fstab entry prevents mount on the resized VM, which then allows for reformat to ext4. If you run into this, just resize again to any size and it should repro then. -----Original Message----- From: