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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1611074
Title:
Reformatting of ephemeral drive fails on resize of Azure VM
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1611074/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
