| 2017-12-12 09:43:25 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2017-12-12 09:43:50 |
Christian Ehrhardt |
summary |
Cloud-init seems not run on today's bionic images |
Cloud-init seems not run on today's bionic images (20171211) |
|
| 2017-12-12 10:52:56 |
Christian Ehrhardt |
bug task added |
|
cloud-init |
|
| 2017-12-12 10:53:56 |
Christian Ehrhardt |
bug task added |
|
cloud-images |
|
| 2017-12-12 14:57:18 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
| 2017-12-12 14:57:28 |
Scott Moser |
bug task deleted |
cloud-images |
|
|
| 2017-12-12 14:57:35 |
Scott Moser |
cloud-init: status |
New |
In Progress |
|
| 2017-12-12 14:57:39 |
Scott Moser |
cloud-init (Ubuntu): status |
Confirmed |
In Progress |
|
| 2017-12-12 14:57:42 |
Scott Moser |
cloud-init: importance |
Undecided |
High |
|
| 2017-12-12 14:57:44 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
High |
|
| 2017-12-12 14:57:47 |
Scott Moser |
cloud-init: assignee |
|
Scott Moser (smoser) |
|
| 2017-12-12 14:57:49 |
Scott Moser |
cloud-init (Ubuntu): assignee |
|
Scott Moser (smoser) |
|
| 2017-12-12 15:22:16 |
Scott Moser |
summary |
Cloud-init seems not run on today's bionic images (20171211) |
Cloud-init fails if iso9660 filesystem on non-cdrom path in 20171211 image. |
|
| 2017-12-12 16:09:09 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/335086 |
|
| 2017-12-12 17:47:44 |
Chad Smith |
description |
Hi,
I had the last daily image working fine:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171129.1)
But today after a sync I got this image:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171211)
The latter is failing me to boot correctly in regard to networking and actually cloud-init in general.
In the guest console I see it hanging on the usual "A start job is running for Wait for ..."
It breaks after some time giving up on networking.
"See 'systemctl status systemd-networkd-wait-online.service' for details."
The host confirmd that - the guest did not get an IP from dnsmasq.
Note: I was able to trigger this on a Xenial host as well as a Bionic Host. Also latest Artful image works well on all of these - so I'd expect it safe to assume that it only depends on the guest image.
I have taken full bootup console logs of both cases.
20171129.1 (good): http://paste.ubuntu.com/26169044/
20171211 (bad): http://paste.ubuntu.com/26169046/
There was one more thing that made me perplex - I usually provide --password=ubunut to uvt-kvm.
That adds a snippet to the cloud-init data to set the password of the ubuntu user.
Connecting via "virsh console" I can't log in on the bad guest which made me assume that cloud-init didn't run at all in the bad case.
And in fact the full logs confirm that, in the bad case there is no cloud-init seen at all.
Also my bionic containers today saw a cloud-init update - maybe it really is broken in the current daily image?
OTOH the changelog of cloud-init didn't suggest a change that could explain this. |
When ds-identify attempted to detect OVF datasource it logs a debug message using an undeclared variable in a debug message resulting in the following failure:
_shwrap: d: parameter not set.
==== Original description ===
Hi,
I had the last daily image working fine:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171129.1)
But today after a sync I got this image:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171211)
The latter is failing me to boot correctly in regard to networking and actually cloud-init in general.
In the guest console I see it hanging on the usual "A start job is running for Wait for ..."
It breaks after some time giving up on networking.
"See 'systemctl status systemd-networkd-wait-online.service' for details."
The host confirmd that - the guest did not get an IP from dnsmasq.
Note: I was able to trigger this on a Xenial host as well as a Bionic Host. Also latest Artful image works well on all of these - so I'd expect it safe to assume that it only depends on the guest image.
I have taken full bootup console logs of both cases.
20171129.1 (good): http://paste.ubuntu.com/26169044/
20171211 (bad): http://paste.ubuntu.com/26169046/
There was one more thing that made me perplex - I usually provide --password=ubunut to uvt-kvm.
That adds a snippet to the cloud-init data to set the password of the ubuntu user.
Connecting via "virsh console" I can't log in on the bad guest which made me assume that cloud-init didn't run at all in the bad case.
And in fact the full logs confirm that, in the bad case there is no cloud-init seen at all.
Also my bionic containers today saw a cloud-init update - maybe it really is broken in the current daily image?
OTOH the changelog of cloud-init didn't suggest a change that could explain this. |
|
| 2017-12-12 17:49:20 |
Chad Smith |
description |
When ds-identify attempted to detect OVF datasource it logs a debug message using an undeclared variable in a debug message resulting in the following failure:
_shwrap: d: parameter not set.
==== Original description ===
Hi,
I had the last daily image working fine:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171129.1)
But today after a sync I got this image:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171211)
The latter is failing me to boot correctly in regard to networking and actually cloud-init in general.
In the guest console I see it hanging on the usual "A start job is running for Wait for ..."
It breaks after some time giving up on networking.
"See 'systemctl status systemd-networkd-wait-online.service' for details."
The host confirmd that - the guest did not get an IP from dnsmasq.
Note: I was able to trigger this on a Xenial host as well as a Bionic Host. Also latest Artful image works well on all of these - so I'd expect it safe to assume that it only depends on the guest image.
I have taken full bootup console logs of both cases.
20171129.1 (good): http://paste.ubuntu.com/26169044/
20171211 (bad): http://paste.ubuntu.com/26169046/
There was one more thing that made me perplex - I usually provide --password=ubunut to uvt-kvm.
That adds a snippet to the cloud-init data to set the password of the ubuntu user.
Connecting via "virsh console" I can't log in on the bad guest which made me assume that cloud-init didn't run at all in the bad case.
And in fact the full logs confirm that, in the bad case there is no cloud-init seen at all.
Also my bionic containers today saw a cloud-init update - maybe it really is broken in the current daily image?
OTOH the changelog of cloud-init didn't suggest a change that could explain this. |
During OVF datasource checks, ds-identify attempted to ignore non-cdrom iso9660 filesystems. It logs a debug 'skip' message using an undeclared variable in a debug message resulting in the following failure:
_shwrap: d: parameter not set.
==== Original description ===
Hi,
I had the last daily image working fine:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171129.1)
But today after a sync I got this image:
$ uvt-simplestreams-libvirt query
release=bionic arch=amd64 label=daily (20171211)
The latter is failing me to boot correctly in regard to networking and actually cloud-init in general.
In the guest console I see it hanging on the usual "A start job is running for Wait for ..."
It breaks after some time giving up on networking.
"See 'systemctl status systemd-networkd-wait-online.service' for details."
The host confirmd that - the guest did not get an IP from dnsmasq.
Note: I was able to trigger this on a Xenial host as well as a Bionic Host. Also latest Artful image works well on all of these - so I'd expect it safe to assume that it only depends on the guest image.
I have taken full bootup console logs of both cases.
20171129.1 (good): http://paste.ubuntu.com/26169044/
20171211 (bad): http://paste.ubuntu.com/26169046/
There was one more thing that made me perplex - I usually provide --password=ubunut to uvt-kvm.
That adds a snippet to the cloud-init data to set the password of the ubuntu user.
Connecting via "virsh console" I can't log in on the bad guest which made me assume that cloud-init didn't run at all in the bad case.
And in fact the full logs confirm that, in the bad case there is no cloud-init seen at all.
Also my bionic containers today saw a cloud-init update - maybe it really is broken in the current daily image?
OTOH the changelog of cloud-init didn't suggest a change that could explain this. |
|
| 2017-12-12 19:01:47 |
Chad Smith |
cloud-init: status |
In Progress |
Fix Committed |
|
| 2017-12-12 19:04:10 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/335099 |
|
| 2017-12-12 20:40:22 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
In Progress |
Fix Released |
|
| 2017-12-14 21:03:17 |
Scott Moser |
cloud-init: status |
Fix Committed |
Fix Released |
|
| 2023-05-11 09:03:58 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/3085 |
|
