group.of.nepali.translators team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: cloud-init
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1686514

Title:
  Azure: cloud-init does not handle reformatting GPT partition ephemeral
  disks

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  On Azure, cloud-init handles re-formatting the ephemeral disk.
  The contents of the ephemeral disk for a system will be replaced with
  a stock ephemeral disk in the following scenarios:
   a.) first boot
   b.) after a resize.
   c.) after a VM has been migrated from one host to another.

  That ephemeral disk is either
   1. mbr partitioned with 1 ntfs partition
   2. gpt partitioned with 2 partitions, a msft reserved partition and a
      ntfs partition.  This scenario is newer, and only occurs on
      larger instance types that have large ephemeral disks.

  cloud-init previously did not handle '2' above.

  [Test Case]
  Generically this is re-creatable by:
   1.) launch an instance on Azure
   2.) resize it to a L32 or G5 size
   3.) check to see that the ephemeral disk (/dev/disk/cloud/azure_resource)
       has been formatted to ext4.

  It is more easily recreated for testing and verification by:

  1. launch instance on azure
  2. re-partition the ephemeral disk to look like a "clean" disk above
  3. remove old logs, reboot
     $ dir=logs-$(date +"%Y%m%d-%H%M%S");
     $ mkdir -p $dir; mv /var/log/cloud-init* $dir
  4. ssh back in, expect that this the disk has an ext4 filesystem on it.
     And that it is mounted on /mnt.

     $ grep reformattable= /var/log/cloud-init.log
     2017-05-12 15:14:57,125 - DataSourceAzure.py[DEBUG]: reformattable=False: partition 1 (/dev/sdb1) on device /dev/disk/cloud/azure_resource was not ntfs formatted

     Or, if it was formatted, you'll see something like:
     2017-05-12 15:17:47,021 - DataSourceAzure.py[DEBUG]: reformattable=True: partition 2 (/dev/sdb2) on device /dev/disk/cloud/azure_resource was ntfs formatted and had no important files. Safe for reformatting.

     $ grep /mnt /proc/mounts
     /dev/sdb1 /mnt ext4 rw,relatime,data=ordered 0 0

  
  [Regression Potential]
  The change makes cloud-init accept another situation when it decides
  to be reformat a disk.  Reformatting of a disk could result in loss of
  customer data if the decision to do so results in a false positive.

  The fix came with some fairly extensive unit tests (TestCanDevBeReformatted)
  on the 'can_dev_be_reformatted' method.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=31b6f1732

  === End SRU Template ===

  
  Some Azure instances such as L32 or G5 have very large ephemeral disks which are partitioned via GPT vs. smaller ephemeral disks that have dos disklabels.

  At first boot of an instance the ephemeral disk is prepared and
  formatted properly. But if the instance is deallocated and then
  reallocated (thus receiving a new ephemeral disk) then cloud-init does
  not handle reformatting GPT partition ephemeral disks properly.
  Therefore /mnt is never mounted again.

  Test cases:
   1. Deploy an L32(s) VM on Azure
   2. Log in and ensure that the ephemeral disk is formatted and mounted to /mnt
   3. Via the portal you can "Redeploy" the VM to a new Azure Host (or alternatively stop and deallocate the VM for some time, and then restart/reallocate the VM).

  Expected Results:
   - After reallocation we expect the ephemeral disk to be formatted and mounted to /mnt.

  Actual Results:
   - After reallocation /mnt is not mounted and there are errors in the cloud-init log.

  *This was tested on Ubuntu 16.04 - but may affect other releases.

  Note: This bug a regression from previous cloud-init releases. GPT
  support for Azure ephemeral disk handling was added to cloud-init via
  this bug: https://bugs.launchpad.net/ubuntu/+source/cloud-
  init/+bug/1422919.

  Related bugs:
   * bug 1691489: fstab entries written by cloud-config may not be mounted

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1686514/+subscriptions