yahoo-eng-team team mailing list archive

[Scott Moser <ssmoser2+ubuntu@xxxxxxxxx>]

This bug is believed to be fixed in cloud-init in 1705804. 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 Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1737704

Title:
  Cloud-init fails if iso9660 filesystem on non-cdrom path in 20171211
  image.

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released

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-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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1737704/+subscriptions