cloud-init (18.2-0ubuntu1) service is not running in ubuntu-18.04-desktop-64

[vmware-gos-Yuhua]

We can install package cloud-init 18.2-0ubuntu1 in newest daily build ubuntu-18.04-desktop64
But after finish installation, find the cloud-init service is not running.

vmare@vmware-virtual-machine:~ systemctl status cloud-init
cloud-init.service -Inital cloud-init job (metadate service crawler)
   Loaded: loaded(/lib/system/system/cloud-init.service;enable; vendor press
   Active: inactive(dead)

this issue doesn't exist in ubuntu-18.04-Server-64.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christian Ehrhardt  (paelzer)]

I think with no config provided it is supposed to disable itself, so it is doing the right thing.
Also see [1] for that.

But there are two things that can help debugging this in any case.

1. please check if it would work and run after reboot
2. after that please fetch and upload here the files
   /var/log/cloud-init-output.log
   /var/log/cloud-init.log

But as I said, without data I assume it is supposed to disable itself.

[1]: https://bugs.launchpad.net/cloud-init/+bug/1750770/comments/8

[Ryan Harper (raharper)]

You can also do:

apport-collect 1760776

and

cloud-init collect-logs # this writes a cloud-init.tar.gz to the current directory

And attach those to this bug.

[Pengpeng Sun (pengpengs)]

reproduced the same issue on Apr.1 build
1. tried reboot, cloud-init service was still inactive.
2. I checked /var/log/cloud-init-output.log, it says 'netstat' cmd not found. After install net-tools, and run "service cloud-init start", still can not active it. /var/log/cloud-init-output.log says Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed

run cloud-init collect-logs and attached .gz

[Dimitri John Ledkov (xnox)]

cloud-init no longer runs, unless ds-identify can identify the platform that this machine is supposed to be configured as.

Thus by default, simply installing cloud-init will be inert.

What data sources are you expecting to use, and have you manually configured /etc/cloud appropriately? Or ensure that your system exposes the correct ds-identify platform?

[Dimitri John Ledkov (xnox)]

When you mention that the issue does not exist with Ubuntu Server -> what do you mean? self-installed ubuntu server? or a VMware specific cloud image? What is the output of ds-identify there? contents of /etc/cloud?

[Pengpeng Sun (pengpengs)]

Yes, I saw 'No ds found [mode=search, notfound=disabled]. Disabled cloud-init' from /run/cloud-init/ds-identify.log, will attach it.

The Ubuntu Server is the server build I downloaded from below link and installed on a VMware VM.
Server: http://cdimage.ubuntu.com/ubuntu-server/daily/current/

I did not manually configure /etc/cloud/cloud.cfg either on that Ubuntu Server, unfortunately the Server VM has been deleted. I will install a new one.

I think ds-identify should be able to find the correct ds on a VMware VM, if not true, what's configure should be set here?

[Pengpeng Sun (pengpengs)]

list -Rl /etc/cloud

.:
cloud.cfg
cloud.cfg.d
templates

./cloud.cfg.d:
05_logging.cfg
90_dpkg.cfg
README

./templates:
chef_client.rb.tmpl
hosts.debian.tmpl
hosts.freebsd.tmpl
hosts.redhat.tmpl
hosts.suse.tmpl
ntp.conf.debian.tmpl
ntp.conf.fedora.tmpl
ntp.conf.opensuse.tmpl
ntp.conf.rhel.tmpl
ntp.conf.sles.tmpl
ntp.conf.ubuntu.tmpl
resolv.conf.tmpl
sources.list.debian.tmpl
sources.list.ubuntu.tmpl
timesyncd.conf.tmpl

[Ryan Harper (raharper)]

On Wed, Apr 4, 2018 at 5:44 AM, Pengpeng Sun <email address hidden> wrote:
> Yes, I saw 'No ds found [mode=search, notfound=disabled]. Disabled
> cloud-init' from /run/cloud-init/ds-identify.log, will attach it.
>
> The Ubuntu Server is the server build I downloaded from below link and installed on a VMware VM.
> Server: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
>
> I did not manually configure /etc/cloud/cloud.cfg either on that Ubuntu
> Server, unfortunately the Server VM has been deleted. I will install a
> new one.
>
> I think ds-identify should be able to find the correct ds on a VMware
> VM, if not true, what's configure should be set here?

cloud-init is looking for a datasource; Did you attach an OVF?
Or an iso with cloud-init user-data?

You're attached ds-identify log shows it found it was running on VMware
but that there were no datasources[1]

VMware typically uses the DatasourceOVF[2], which can be provided to
an image through different transports.

1. http://cloudinit.readthedocs.io/en/latest/topics/datasources.html
2. https://git.launchpad.net/cloud-init/tree/doc/sources/ovf/README

[Ryan Harper (raharper)]

> this issue doesn't exist in ubuntu-18.04-Server-64.

The server image for 18.04 uses cloud-init during its initial boot as part of how the new server installer works; The desktop does not use cloud-init in any way; it is not expected to run desktop images; cloud-init is a boot-time service for image customization given a Datasource with configuration.

[Ryan Harper (raharper)]

I'm marking this bug as invalid as the scenario described is not valid. Installing cloud-init into a desktop image does not mean that cloud-init service will run; it's a boot time service that requires providing cloud-init a valid datasource. If you disagree, please reopen and provide further details on how you provided cloud-init configuration in the desktop scenario.

[Christian Ehrhardt  (paelzer)]

Also not an open-vm-tools issue, setting invalid on that as well.

[David Estes (davydotcom)]

This appears to be an entirely valid bug. VMWARE does not always use DatasourceOVF. When using OpenStack VIO (Openstack on VMWARE) the ec2 datasource fallback is no longer being used as of this more recent update. OpenStack VIO exposes user-data on 169.254.169.254 but now we get a platform unknown

[Ryan Harper (raharper)]

@David generally running on OpenStack, instances already identify themselves as OpenStack via DMI properties.

It sounds like you've an instance that has failed, please open a new bug against cloud-init and in there if you could you please run:

  $ cloud-init collect-logs
  $ sudo sh -c 'cd /sys/hypervisor && grep -r . *'
  $ sudo sh -c 'cd /sys/class/dmi/id && grep -r . *'

and attach the output to the new bug.