yahoo-eng-team team mailing list archive

[Jason Zions <1825596@xxxxxxxxxxxxxxxxxx>]

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