This is fixed in cloud-init 0.7.9.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626243
Title:
Cloud-init fails to write ext4
This bug was fixed in the package cloud-init - 0.7.8-49-g9e904bb-
0ubuntu1~16.10.1
---
cloud-init (0.7.8-49-g9e904bb-0ubuntu1~16.10.1) yakkety; urgency=medium
* debian/cloud-init.templates: enable DigitalOcean by default [Ben Howard]
* debian/cloud-init.postinst: update /etc/fstab
I've verified this using:
$ dpkg-query --show cloud-init
cloud-init 0.7.8-49-g9e904bb-0ubuntu1~16.10.1
$ cat /etc/cloud/build.info
build_name: server
serial: 20161214
I basically did the same as in comment 12 with 'yakkety' instead of
'xenial'
** Tags removed: verification-needed
** Tags ad
Hello Matt, or anyone else affected,
Accepted cloud-init into yakkety-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/cloud-
init/0.7.8-49-g9e904bb-0ubuntu1~16.10.1 in a few hours, and then in the
-proposed repository.
Please help us by testing this n
This bug was fixed in the package cloud-init - 0.7.8-49-g9e904bb-
0ubuntu1~16.04.1
---
cloud-init (0.7.8-49-g9e904bb-0ubuntu1~16.04.1) xenial-proposed; urgency=medium
* debian/cloud-init.postinst: update /etc/fstab on Azure to fix
future resize operations. (LP: #1611074)
* New
I've verified this xenial with the following. The net is that when a
new instance came across an empty ephemeral disk, it put a gpt partition
table on it, with one partition, and formatted it ext4.
## Launch an azure instance and ssh in
$ azure-ubuntu xenial . --user-data-file=none Standard_D1_v
Correction, if I follow the workflow (upgrade cloud-init -> reboot ->
resize) then the ephemeral drive is formatted properly. If this ins
intended functionality (reboot is required before resize) then we can
consider bug 1611074 resolved as well.
--
You received this bug notification because you
Thanks for your help Steve and Scott. I ran a test with 100 VM's (custom image
with this version of cloud-init included) and all 100 successfully came up with
/mnt formatted as ext4. So I think this bug is sorted out.
However, I'm still able to repro bug 1611074 when I resize a VM with this
vers
** Description changed:
=== Begin SRU Template ===
- [Impact]
+ [Impact]
There is a race condition that occurs when cloud-init tries to partition a
block device (/dev/sdb) and then put a filesystem on a partition on it. It is
possible that cloud-init tries to run mkfs on /dev/sdb1 after
Hello Matt, or anyone else affected,
Accepted cloud-init into xenial-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/cloud-
init/0.7.8-47-gb6561a1-0ubuntu1~16.04.1 in a few hours, and then in the
-proposed repository.
Please help us by testing this ne
** Description changed:
- The symptom is similar to bug 1611074 but the cause is different. In
- this case it seems there is an error accessing /dev/sdb1 when lsblk is
- run, possibly because sgdisk isn't done creating the partition. The
- specific error message is "/dev/sdb1: not a block device."
** Also affects: cloud-init (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Zesty)
Importance: Medium
Status: Fix Released
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: cloud-init
Users continue to hit this issue every day in Xenial, I don't see how
they'll be mitigated without backporting the fix. Can we get an ETA for
backporting to Xenial?
Thanks again,
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
Thanks for the quick response, in my testing I've been unable to repro
the issue. Will this be backported to Xenial? Users will continue to hit
this issue until the fix is backported.
Thanks again
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
This bug was fixed in the package cloud-init - 0.7.8-27-g29348af-
0ubuntu1
---
cloud-init (0.7.8-27-g29348af-0ubuntu1) zesty; urgency=medium
* debian/cloud-init.templates: enable DigitalOcean by default [Ben Howard]
* New upstream snapshot.
- disk-config: udev settle after par
** Changed in: cloud-init
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626243
Title:
Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive
T
We don't have a reliable repro but would be glad to test out a fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626243
Title:
Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive
T
It really does seem like this is an obvious case of needing to udevadm
settle so that the partition exists after partitioning and before
formatting.
I'm attaching a little shell script that really should reproduce the
failure, but I can't get it to.
** Attachment added: "script should reproduce
How easily can you recreate this? If I give you a patched cloud-init,
could you be reasonably sure that it was now fixed?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626243
Title:
Cloud-init fai
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init (U
20 matches
Mail list logo
