| 2017-05-19 19:17:18 |
Anubhuti Manohar |
bug |
|
|
added bug |
| 2017-05-19 21:08:30 |
Anubhuti Manohar |
attachment added |
|
Attaching cloud init logs https://bugs.launchpad.net/cloud-init/+bug/1692093/+attachment/4879826/+files/cloud-init.tar |
|
| 2017-05-19 21:14:11 |
Anubhuti Manohar |
bug |
|
|
added subscriber Paul Meyer |
| 2017-05-20 05:55:53 |
Paul Meyer |
attachment added |
|
logs from the first boot, the first reboot and a reboot after adding a 'udevadm settle' https://bugs.launchpad.net/cloud-init/+bug/1692093/+attachment/4879980/+files/cloudinit.zip |
|
| 2017-05-20 05:56:05 |
Paul Meyer |
cloud-init: status |
New |
Confirmed |
|
| 2017-05-20 05:56:18 |
Paul Meyer |
cloud-init: assignee |
|
Paul Meyer (paul-meyer) |
|
| 2017-05-20 06:02:59 |
Paul Meyer |
merge proposal linked |
|
https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/324359 |
|
| 2017-05-25 16:14:50 |
Scott Moser |
cloud-init: importance |
Undecided |
Medium |
|
| 2017-05-25 17:09:27 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324639 |
|
| 2017-05-26 20:25:25 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2017-05-26 20:25:58 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Fix Released |
|
| 2017-05-26 20:26:01 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-05-26 20:26:11 |
Scott Moser |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-05-26 20:26:11 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Zesty) |
|
| 2017-05-26 20:26:11 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-05-26 20:26:11 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2017-05-26 20:26:11 |
Scott Moser |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-05-26 20:26:11 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Yakkety) |
|
| 2017-05-26 20:26:25 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-05-26 20:26:29 |
Scott Moser |
cloud-init (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-05-26 20:26:31 |
Scott Moser |
cloud-init (Ubuntu Zesty): status |
New |
Confirmed |
|
| 2017-05-26 20:26:34 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-05-26 20:26:37 |
Scott Moser |
cloud-init (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
| 2017-05-26 20:26:40 |
Scott Moser |
cloud-init (Ubuntu Zesty): importance |
Undecided |
Medium |
|
| 2017-06-02 18:12:21 |
Scott Moser |
cloud-init: status |
Confirmed |
Fix Committed |
|
| 2017-06-02 18:35:32 |
Chad Smith |
description |
Cloud Provider: Azure
dpkg-query -W -f='${Version}' cloud-init output: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1
When the following is specified in cloud init it seems to be re-executing fs and disk setup (even though run command does not seem to re run)
disk_setup:
/dev/sdc:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- label: etcd_disk
filesystem: ext4
device: /dev/sdc1
extra_opts:
- "-F"
- "-E"
- "lazy_itable_init=1,lazy_journal_init=1"
mounts:
- - /dev/sdc1
- /var/lib/etcddisk
From cloud-init-output.log:
Cloud-init v. 0.7.9 running 'modules:final' at Mon, 15 May 2017 18:33:15 +0000. Up 64.24 seconds.
Cloud-init v. 0.7.9 finished at Mon, 15 May 2017 18:34:46 +0000. Datasource DataSourceAzureNet [seed=/dev/sr0]. Up 155.34 seconds
Cloud-init v. 0.7.9 running 'init-local' at Tue, 16 May 2017 01:52:37 +0000. Up 10.33 seconds.
Cloud-init v. 0.7.9 running 'init' at Tue, 16 May 2017 01:52:39 +0000. Up 12.06 seconds.
From cloud-init.log for the initial provision:
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-15 18:32:46,820 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True)
2017-05-15 18:33:04,054 - util.py[DEBUG]: Creating fs for /dev/sdc1 took 17.237 seconds
and after reboot (cloud-init.log)
2017-05-16 01:52:40,245 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-16 01:52:40,246 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-16 01:52:40,246 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True) |
http://pad.lv/1692093
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1692093
=== Begin SRU Template ===
[Impact]
VMs on MS Azure have an ephemeral disk attached to them.
On first boot, cloud-init properly notices the empty ntfs filesystem and
reformats it ext4.
After deallocating the instance or moving to a new azure host,
the filesystem reformat is logged, but isn't actually performed because
the udev device creation may not have settled.
[Test Case]
Test cases:
1. Deploy an instance 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:a
- Check cloud-init.log expecting to see logs from cc_disk_setup about the mount.
- 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.
[Regression Potential]
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=1815c6d801933c47a01f1a94a8e689824f6797b4
=== End SRU Template ===
Cloud Provider: Azure
dpkg-query -W -f='${Version}' cloud-init output: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1
When the following is specified in cloud init it seems to be re-executing fs and disk setup (even though run command does not seem to re run)
disk_setup:
/dev/sdc:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- label: etcd_disk
filesystem: ext4
device: /dev/sdc1
extra_opts:
- "-F"
- "-E"
- "lazy_itable_init=1,lazy_journal_init=1"
mounts:
- - /dev/sdc1
- /var/lib/etcddisk
From cloud-init-output.log:
Cloud-init v. 0.7.9 running 'modules:final' at Mon, 15 May 2017 18:33:15 +0000. Up 64.24 seconds.
Cloud-init v. 0.7.9 finished at Mon, 15 May 2017 18:34:46 +0000. Datasource DataSourceAzureNet [seed=/dev/sr0]. Up 155.34 seconds
Cloud-init v. 0.7.9 running 'init-local' at Tue, 16 May 2017 01:52:37 +0000. Up 10.33 seconds.
Cloud-init v. 0.7.9 running 'init' at Tue, 16 May 2017 01:52:39 +0000. Up 12.06 seconds.
From cloud-init.log for the initial provision:
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-15 18:32:46,820 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True)
2017-05-15 18:33:04,054 - util.py[DEBUG]: Creating fs for /dev/sdc1 took 17.237 seconds
and after reboot (cloud-init.log)
2017-05-16 01:52:40,245 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-16 01:52:40,246 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-16 01:52:40,246 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True) |
|
| 2017-06-02 18:56:54 |
Scott Moser |
description |
http://pad.lv/1692093
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1692093
=== Begin SRU Template ===
[Impact]
VMs on MS Azure have an ephemeral disk attached to them.
On first boot, cloud-init properly notices the empty ntfs filesystem and
reformats it ext4.
After deallocating the instance or moving to a new azure host,
the filesystem reformat is logged, but isn't actually performed because
the udev device creation may not have settled.
[Test Case]
Test cases:
1. Deploy an instance 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:a
- Check cloud-init.log expecting to see logs from cc_disk_setup about the mount.
- 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.
[Regression Potential]
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=1815c6d801933c47a01f1a94a8e689824f6797b4
=== End SRU Template ===
Cloud Provider: Azure
dpkg-query -W -f='${Version}' cloud-init output: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1
When the following is specified in cloud init it seems to be re-executing fs and disk setup (even though run command does not seem to re run)
disk_setup:
/dev/sdc:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- label: etcd_disk
filesystem: ext4
device: /dev/sdc1
extra_opts:
- "-F"
- "-E"
- "lazy_itable_init=1,lazy_journal_init=1"
mounts:
- - /dev/sdc1
- /var/lib/etcddisk
From cloud-init-output.log:
Cloud-init v. 0.7.9 running 'modules:final' at Mon, 15 May 2017 18:33:15 +0000. Up 64.24 seconds.
Cloud-init v. 0.7.9 finished at Mon, 15 May 2017 18:34:46 +0000. Datasource DataSourceAzureNet [seed=/dev/sr0]. Up 155.34 seconds
Cloud-init v. 0.7.9 running 'init-local' at Tue, 16 May 2017 01:52:37 +0000. Up 10.33 seconds.
Cloud-init v. 0.7.9 running 'init' at Tue, 16 May 2017 01:52:39 +0000. Up 12.06 seconds.
From cloud-init.log for the initial provision:
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-15 18:32:46,820 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True)
2017-05-15 18:33:04,054 - util.py[DEBUG]: Creating fs for /dev/sdc1 took 17.237 seconds
and after reboot (cloud-init.log)
2017-05-16 01:52:40,245 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-16 01:52:40,246 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-16 01:52:40,246 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True) |
=== Begin SRU Template ===
[Impact]
VMs on MS Azure have an ephemeral disk attached to them.
On first boot, cloud-init properly notices the empty ntfs filesystem and
reformats it ext4.
After deallocating the instance or moving to a new azure host,
the filesystem reformat is logged, but isn't actually performed because
the udev device creation may not have settled.
[Test Case]
Test cases:
1. Deploy an instance 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:a
- Check cloud-init.log expecting to see logs from cc_disk_setup about the mount.
- 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.
[Regression Potential]
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=1815c6d801933c47a01f1a94a8e689824f6797b4
=== End SRU Template ===
Cloud Provider: Azure
dpkg-query -W -f='${Version}' cloud-init output: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1
When the following is specified in cloud init it seems to be re-executing fs and disk setup (even though run command does not seem to re run)
disk_setup:
/dev/sdc:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- label: etcd_disk
filesystem: ext4
device: /dev/sdc1
extra_opts:
- "-F"
- "-E"
- "lazy_itable_init=1,lazy_journal_init=1"
mounts:
- - /dev/sdc1
- /var/lib/etcddisk
From cloud-init-output.log:
Cloud-init v. 0.7.9 running 'modules:final' at Mon, 15 May 2017 18:33:15 +0000. Up 64.24 seconds.
Cloud-init v. 0.7.9 finished at Mon, 15 May 2017 18:34:46 +0000. Datasource DataSourceAzureNet [seed=/dev/sr0]. Up 155.34 seconds
Cloud-init v. 0.7.9 running 'init-local' at Tue, 16 May 2017 01:52:37 +0000. Up 10.33 seconds.
Cloud-init v. 0.7.9 running 'init' at Tue, 16 May 2017 01:52:39 +0000. Up 12.06 seconds.
From cloud-init.log for the initial provision:
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-15 18:32:46,820 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True)
2017-05-15 18:33:04,054 - util.py[DEBUG]: Creating fs for /dev/sdc1 took 17.237 seconds
and after reboot (cloud-init.log)
2017-05-16 01:52:40,245 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-16 01:52:40,246 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-16 01:52:40,246 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True) |
|
| 2017-06-13 17:06:23 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
VMs on MS Azure have an ephemeral disk attached to them.
On first boot, cloud-init properly notices the empty ntfs filesystem and
reformats it ext4.
After deallocating the instance or moving to a new azure host,
the filesystem reformat is logged, but isn't actually performed because
the udev device creation may not have settled.
[Test Case]
Test cases:
1. Deploy an instance 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:a
- Check cloud-init.log expecting to see logs from cc_disk_setup about the mount.
- 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.
[Regression Potential]
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=1815c6d801933c47a01f1a94a8e689824f6797b4
=== End SRU Template ===
Cloud Provider: Azure
dpkg-query -W -f='${Version}' cloud-init output: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1
When the following is specified in cloud init it seems to be re-executing fs and disk setup (even though run command does not seem to re run)
disk_setup:
/dev/sdc:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- label: etcd_disk
filesystem: ext4
device: /dev/sdc1
extra_opts:
- "-F"
- "-E"
- "lazy_itable_init=1,lazy_journal_init=1"
mounts:
- - /dev/sdc1
- /var/lib/etcddisk
From cloud-init-output.log:
Cloud-init v. 0.7.9 running 'modules:final' at Mon, 15 May 2017 18:33:15 +0000. Up 64.24 seconds.
Cloud-init v. 0.7.9 finished at Mon, 15 May 2017 18:34:46 +0000. Datasource DataSourceAzureNet [seed=/dev/sr0]. Up 155.34 seconds
Cloud-init v. 0.7.9 running 'init-local' at Tue, 16 May 2017 01:52:37 +0000. Up 10.33 seconds.
Cloud-init v. 0.7.9 running 'init' at Tue, 16 May 2017 01:52:39 +0000. Up 12.06 seconds.
From cloud-init.log for the initial provision:
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-15 18:32:46,820 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True)
2017-05-15 18:33:04,054 - util.py[DEBUG]: Creating fs for /dev/sdc1 took 17.237 seconds
and after reboot (cloud-init.log)
2017-05-16 01:52:40,245 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-16 01:52:40,246 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-16 01:52:40,246 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True) |
=== Begin SRU Template ===
[Impact]
VMs on MS Azure have an ephemeral disk attached to them.
On first boot, cloud-init properly notices the empty ntfs filesystem and
reformats it ext4.
After deallocating the instance or moving to a new azure host,
the filesystem reformat is logged, but isn't actually performed because
the udev device creation may not have settled.
[Test Case]
Test cases:
1. Deploy an instance 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:a
- Check cloud-init.log expecting to see logs from cc_disk_setup about the mount.
- 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.
[Regression Potential]
Regression potential should be extremely low on this change.
Essentially the change was to add the function 'assert_and_settle_device' and
then to use it. See the commit linked below.
The most likely regression is just slower boot. The most likely unexpected change in behavior is getting a RunTimeError due to 'assert_and_settle_device' realizing that there is no device present. That would have ultimately just resulted in a different error with less obvious error message.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=1815c6d801933c47a01f1a94a8e689824f6797b4
=== End SRU Template ===
Cloud Provider: Azure
dpkg-query -W -f='${Version}' cloud-init output: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1
When the following is specified in cloud init it seems to be re-executing fs and disk setup (even though run command does not seem to re run)
disk_setup:
/dev/sdc:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- label: etcd_disk
filesystem: ext4
device: /dev/sdc1
extra_opts:
- "-F"
- "-E"
- "lazy_itable_init=1,lazy_journal_init=1"
mounts:
- - /dev/sdc1
- /var/lib/etcddisk
From cloud-init-output.log:
Cloud-init v. 0.7.9 running 'modules:final' at Mon, 15 May 2017 18:33:15 +0000. Up 64.24 seconds.
Cloud-init v. 0.7.9 finished at Mon, 15 May 2017 18:34:46 +0000. Datasource DataSourceAzureNet [seed=/dev/sr0]. Up 155.34 seconds
Cloud-init v. 0.7.9 running 'init-local' at Tue, 16 May 2017 01:52:37 +0000. Up 10.33 seconds.
Cloud-init v. 0.7.9 running 'init' at Tue, 16 May 2017 01:52:39 +0000. Up 12.06 seconds.
From cloud-init.log for the initial provision:
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-15 18:32:46,820 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True)
2017-05-15 18:33:04,054 - util.py[DEBUG]: Creating fs for /dev/sdc1 took 17.237 seconds
and after reboot (cloud-init.log)
2017-05-16 01:52:40,245 - cc_disk_setup.py[DEBUG]: Creating file system etcd_disk on /dev/sdc1
2017-05-16 01:52:40,246 - cc_disk_setup.py[DEBUG]: Using cmd: /sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E lazy_itable_init=1,lazy_journal_init=1
2017-05-16 01:52:40,246 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', '/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] (shell=False, capture=True) |
|
| 2017-06-13 18:09:12 |
Brian Murray |
cloud-init (Ubuntu Zesty): status |
Confirmed |
Fix Committed |
|
| 2017-06-13 18:09:13 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-06-13 18:09:18 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-06-13 18:09:24 |
Brian Murray |
tags |
|
verification-needed |
|
| 2017-06-13 18:56:10 |
Brian Murray |
cloud-init (Ubuntu Yakkety): status |
Confirmed |
Fix Committed |
|
| 2017-06-13 19:09:40 |
Brian Murray |
cloud-init (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2017-06-21 21:36:07 |
Joshua Powers |
tags |
verification-needed |
verification-done-xenial verification-done-yakkety verification-done-zesty |
|
| 2017-06-27 15:51:34 |
Launchpad Janitor |
cloud-init (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-06-27 15:52:57 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-06-27 15:54:02 |
Launchpad Janitor |
cloud-init (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2017-06-27 15:54:45 |
Launchpad Janitor |
cloud-init (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-09-23 02:33:08 |
Scott Moser |
cloud-init: status |
Fix Committed |
Fix Released |
|
| 2023-05-11 01:55:29 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/2898 |
|
