Public bug reported:
If an Azure VM is rebooted after being moved to a different host (e.g.
after a deallocate operation or after a service-heal to remove a bad
host from service), the ephemeral drive exposed to the VM is reset to
the default state (NTFS format). The Azure data source detects this and
marks cc_disk_setup and cc_mounts to be run. While cc_disk_setup
reformats the volume as desired, cc_mounts determines that the
appropriate mount request was already in /etc/fstab (as setup during
initial provisioning). Since the normal boot process would already have
mounted everything according to fstab, the cc_mounts logic is "no mount
-a is required". This is not true in this scenario.
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1825596
Title:
Azure reboot with unformatted ephemeral drive won't mount reformatted
volume
Status in cloud-init:
New
Bug description:
If an Azure VM is rebooted after being moved to a different host (e.g.
after a deallocate operation or after a service-heal to remove a bad
host from service), the ephemeral drive exposed to the VM is reset to
the default state (NTFS format). The Azure data source detects this
and marks cc_disk_setup and cc_mounts to be run. While cc_disk_setup
reformats the volume as desired, cc_mounts determines that the
appropriate mount request was already in /etc/fstab (as setup during
initial provisioning). Since the normal boot process would already
have mounted everything according to fstab, the cc_mounts logic is "no
mount -a is required". This is not true in this scenario.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1825596/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
