Cloud-init fails if iso9660 filesystem on non-cdrom path in 20171211 image.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
Scott Moser | ||
cloud-init (Ubuntu) |
Fix Released
|
High
|
Scott Moser |
Bug Description
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-simplestrea
release=bionic arch=amd64 label=daily (20171129.1)
But today after a sync I got this image:
$ uvt-simplestrea
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-
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://
20171211 (bad): http://
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.
Related branches
- Server Team CI bot: Approve (continuous-integration)
- Joshua Powers (community): Approve
- cloud-init Commiters: Pending requested
-
Diff: 104 lines (+38/-4)4 files modifieddebian/changelog (+9/-0)
tests/cloud_tests/collect.py (+2/-2)
tests/unittests/test_ds_identify.py (+25/-0)
tools/ds-identify (+2/-2)
- Ryan Harper: Approve
- Joshua Powers (community): Approve
- Chad Smith: Approve
- Server Team CI bot: Approve (continuous-integration)
-
Diff: 72 lines (+27/-2)2 files modifiedtests/unittests/test_ds_identify.py (+25/-0)
tools/ds-identify (+2/-2)
summary: |
- Cloud-init seems not run on today's bionic images + Cloud-init seems not run on today's bionic images (20171211) |
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. |
description: | updated |
description: | updated |
Changed in cloud-init: | |
status: | In Progress → Fix Committed |
Since I can't log into the guest due to the lack of proper init in the bad case I copied and mounted both daily images to check how they start fresh.
I see different cloud-init versions: g76243487- 0ubuntu1 ga5dc0f42- 0ubuntu1
good: 17.1-41-
bad: 17.1-53-
I see status and clean commands got added, but none of these should be the kill switch.
I checked out the more reasonable changes in config and/or systemd files, but they all are of the same md5.
Going slightly wider on what actually changed: http:// paste.ubuntu. com/26169161/
The only change left that IMHO could cause this is the one in ds-identify.
Now while I can't really use the new image, I can check what ds-identify left there on its first init (if anything).
But that seems equal, the only thing that differs in: build.info" which refers to the different image date.
$ md5sum $(find /etc/cloud/ -type f | sort | xargs)
is "/etc/cloud/
I fail to see why it didn't run so far :-/