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
This bug was fixed in the package cloud-init - 0.7.9-153-g16a7302f-
0ubuntu1~16.04.1
---
cloud-init (0.7.9-153-g16a7302f-0ubuntu1~16.04.1) xenial-proposed;
urgency=medium
* New upstream snapshot.
- net: fix reading and rendering addresses in cidr format.
[Dimitri John
This bug was fixed in the package cloud-init - 0.7.9-153-g16a7302f-
0ubuntu1~16.10.1
---
cloud-init (0.7.9-153-g16a7302f-0ubuntu1~16.10.1) yakkety-proposed;
urgency=medium
* New upstream snapshot.
- net: fix reading and rendering addresses in cidr format.
[Dimitri John
This bug was fixed in the package cloud-init - 0.7.9-153-g16a7302f-
0ubuntu1~17.04.1
---
cloud-init (0.7.9-153-g16a7302f-0ubuntu1~17.04.1) zesty-proposed; urgency=medium
* New upstream snapshot.
- net: fix reading and rendering addresses in cidr format.
[Dimitri John
Because this resolves the original issues and the new issue is covered
by bug 1691489 I am marking this as verification-done-zesty. Thanks
Scott!
** Tags removed: verification-failed-zesty
** Tags added: verification-done-zesty
--
You received this bug notification because you are a member of
Josh,
The bug you see when it does not work properly is bug 1691489.
The issue as seen in your cloud-init.log is that when mkfs is run its check to
see if the device is used fails. That is because the device is in use by the
fsck process that is being run on filesystem that is already present
Zesty Steps to reproduce
1. Launch an L32s instance with 17.04 (Zesty)
2. Verify /mnt is mounted (mount or lsblk)
3. Update to proposed
4. From Azure console, redeploy the instance
5. Login and look if /mnt is mounted. If it is mounted, GOTO 4
I have seen it work properly before, so a second
I tested Xenial as well and verified that the cloud-init package in
proposed resolves this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686514
Title:
Azure: cloud-init does not handle
I am marking this verification-done-xenial and verification-done-yakkety
as those tests passed.
Zesty is being marked verification-failed-zesty due to the above issue.
I am working on reproducing and collecting additional details.
** Tags removed: verification-needed
** Tags added:
This failed verification on an Azure L32s Zesty instance.
Steps to reproduce:
1. Booted an L32s instance.
2. Redeployed and verified that /mnt was not mounted.
3. Upgraded to the version of cloud-init to proposed, deleted /var/lib/cloud/,
and rebooted.
4. Upon reboot /mnt was not mounted as
Hello Stephen, 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.9-153-g16a7302f-0ubuntu1~16.04.1 in a few hours, and then in
the -proposed repository.
Please help us by testing
Hello Stephen, 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.9-153-g16a7302f-0ubuntu1~16.10.1 in a few hours, and then in
the -proposed repository.
Please help us by testing
Hello Stephen, or anyone else affected,
Accepted cloud-init into zesty-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/cloud-
init/0.7.9-153-g16a7302f-0ubuntu1~17.04.1 in a few hours, and then in
the -proposed repository.
Please help us by testing
** Description changed:
- 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.
+ === Begin SRU Template ===
+ [Impact]
+ On Azure, cloud-init handles re-formatting the ephemeral disk.
+ The
Bug 1692087
I expect that this should be functional for you now. There are still some
issues left that Paul has filed in bug 1692093.
I'll propose a merge for that tomorrow.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Scott,
Do you have a new bug number for the issue in comment #13?
Thanks,
Steve
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686514
Title:
Azure: cloud-init does not handle reformatting GPT
This bug was fixed in the package cloud-init -
0.7.9-144-g2825a917-0ubuntu1
---
cloud-init (0.7.9-144-g2825a917-0ubuntu1) artful; urgency=medium
* New upstream snapshot.
- flake8: move the pinned version of flake8 up to 3.3.0
- tests: Apply workaround for snapd bug in test
Well, now I'm not so sure. I can reproduce this I think.
I'll open a separate bug tomorrow. The issue I think now is that
'check_partition_layout' is deciding that it does not need to repartition.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Stephen,
I think the issue in your comment above is that cloud-init on the first boot
wrote an entry into /etc/fstab for the swap partition. Then you upgraded
rebooted. The /etc/fstab entry for swap was still present and systemd mounted
swap. Then, when cloud-init went to repartition, the
Hi Scott,
As an additional test case I've tried to use the steps as described here
to re-partition the ephemeral disk:
https://wiki.ubuntu.com/AzureSwapPartitions.
Using your branch from this bug the sult is that it appears to fail to
repartition but it does format/mount the disks. Here are my
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Artful)
Importance: High
Assignee: Scott Moser (smoser)
Status: In
** Changed in: cloud-init
Status: In Progress => Fix Committed
** Changed in: cloud-init
Assignee: (unassigned) => Scott Moser (smoser)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've opened up bug 1691489 to address the mount/fsck race, and have been
able to reproduce it and it looks like the fix i had in mind will work
(more info there).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
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
Stephen,
I think this could be an issue that I saw as a possible issue a while ago, but
never reproduced.
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/bug/before-fsck
has some details.
For what is normally responsible for mounting the ephemeral disk... its
supposed to be
Hi Scott,
The linked branch seems to reliably format the ephemeral disk on large
instances. However, after redeploying the VM I don't see the ephemeral
disk mounted after boot. The cloud-init log does not indicate any error,
and if I type 'mount -a' (or do a simple reboot) then the disk is
Stephen,
I believe the linked branch has a suitable fix for this issue now.
In response to my comment #6, I've realized that the 'replace_fs' in
fs_setup configuration was always ignored, because if a partition is
provided (in the "dotted" format there), then replace_fs is not used.
I've tested
I've linked an in-progress branch
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323420
more work to do, but I think i have acceptable fixes there for the
address_ephemeral_resize().
I think we still will need to modify somehow the builtin 'fs_setup' so
that the disk_setup
Hi,
Steven, Thanks for the good analysis.
I think we have a good understanding of the problem.
I'm working on getting a fix for the issue and also the TypeError that
you pointed out.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: cloud-init (Ubuntu)
Importance: Medium => High
** Changed in: cloud-init (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686514
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => Medium
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Confirmed
** Changed in: cloud-init
** Changed in: cloud-init (Ubuntu)
Assignee: (unassigned) => Scott Moser (smoser)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686514
Title:
Azure: cloud-init does not handle reformatting
the issue has been reproduced for Ubuntu 14.04LTS images in azure L32S
instance.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686514
Title:
Azure: cloud-init does not handle reformatting GPT
GPT formatted ephemeral disks have two partitions (unfortunately). The
first is the Microsoft reserved partition
(https://en.wikipedia.org/wiki/Microsoft_Reserved_Partition). This
appears to be tripping up can_dev_be_reformatted().
Function address_ephemeral_resize() will first check if
Adding cloud-init logs. The logs show a number of boots (sorry), but
you should just be able to look at the first two boots to see the issue.
** Attachment added: "cloud-init-output.log"
** Attachment added: "cloud-init.log"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1686514/+attachment/4868359/+files/cloud-init.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
36 matches
Mail list logo
