group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #16606
[Bug 1691489] Re: fstab entries written by cloud-config may not be mounted
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 नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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