yahoo-eng-team 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: Confirmed => Fix Released

-- 
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/1691489

Title:
  fstab entries written by cloud-config may not be mounted

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Won't Fix
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  There is a race condition on a re-deployment of cloud-init on Azure
  where /mnt will not get properly formatted or mounted.  This is due to
  "dirty" entries in /etc/fstab that cause a device to be busy when
  cloud-init goes to format it.  This shows itself usually as 'mkfs'
  complaining that the device is busy.  The cause is that systemd
  starts an fsck and collides with cloud-init re-formatting the disk.

  The problem can be seen other places but seemed to be most reproducible
  and originally found on Azure.

  [Test Case]
  1.) Launch a Azure vm, ideally size L32S.
  2.) Log in and verify the system properly mounted /mnt.
  3.) Re-deploy the vm through the web ui and try again.

  [Regression Potential]
  Worst case scenario, these changes unnecessarily slow down boot and
  do not fix the problem.

  [Regression]
  This SRU change caused bug 1717477.

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

  === End SRU Template ===

  As reported in bug 1686514, sometimes /mnt will not get mounted when
  re-delpoying or stopping-then-starting a Azure vm of L32S.  This is
  probably a more generic issue, I suspect shown due to the speed of
  disks on these systems.

  Related bugs:
   * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks
   * bug 1717477: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck

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