Cloud-init does not run


I try to configure openSUSE 42.3 VMs using cloud-init with the nocloud datasource. I created an iso which works without any problems in Debian, RHEL/CentOS and Ubuntu. Only in opensuse, it does not work. By ‘not work’ I mean, that it does not get loaded or executed at any time in the boot process. I do not see anything in /var/log, (actually, /var/log/cloud-init.log does not exist after booting), nor in dmesg or journal. I enabled all the services (cloud-init.service, cloud-init-local.service, cloud-config.service and cloud-final.service) but still no result. I know the iso works, because after running

cloud-init init

everything looks fine. Has anyone an idea where I might look for further hints?

For each of the services you created, check the status with the following command which should include a log snippet relevant to the service’s successful startup or failure.

systemctl status *service_name* 

If you have problems interpreting the results, post them for all to see and comment.

If the results say that they all started successfully and are running, then if you created Unit files, you should post those as well. Else, if you’re deploying only the standard init files, that’s probably of less interest.


The service files are the ones shipped with the installation of cloud-init-17.1-34.2.x86_64 and cloud-init-config-suse-17.1-34.2.x86_64 from the openSuSE Update OSS repo. As they are oneshot-units, all their statuses look the same:

linux-7ymr:~ # systemctl status cloud-init.service
cloud-init.service - Initial cloud-init job (metadata service crawler)
  Loaded: loaded (/usr/lib/systemd/system/cloud-init.servicel; enabledl; vendor preset: disabled)
  Active: inactive (dead)

I have no logs or anything to work on, it “simply does not run”:

linux-7ymr:~ # ls -l /var/log/cloud*
ls: cannot access '/var/log/cloud*': No such file or directory
linux-7ymr:~ # journalctl | grep cloud | wc -l
linux-7ymr:~ # dmesg | grep cloud | wc -l

What is your result when you run the following?

systemctl start cloud-init.service

You might also get results by searching your journal in the following ways…

Return errors (all levels) in your current boot log

journalctl -p err -b

All entries related to your cloud.init.service running within the last 24 hrs (You can also pass other time constraint filters like within the past hour, last week, specify minutes etc)

journalctl -u cloud-init.service --since today

BTW - did you manually type in the “systemctl status” result in your earlier post?
I see what might be typos… If you copy and pasted, then you might have an odd problem.


If I run

systemctl start cloud-init.service

it runs just fine. Journalctl only reports an error in wickedd:

May 24 16:01:53 linux-7ymr audispd[836]: No plugins found, exiting
May 24 16:01:56 linux-7ymr wickedd[988]: ni_process_reap: process 1434 has not exited yet; now doing a blocking waitpid()
May 24 16:06:56 linux-7ymr wickedd[988]: ni_process_reap: process 5545 has not exited yet; now doing a blocking waitpid()
May 24 16:16:56 linux-7ymr wickedd[988]: ni_process_reap: process 13409 has not exited yet; now doing a blocking waitpid()
... (it just goes on with wickedd errors every 10mins)

And yes, I had to type it in manually. I work on the serial console of HyperV over RDP on a windows server. Don’t ask - copy/paste is just not working :slight_smile:

journalctl -u cloud-init.service

only shows the entries generated by my manual run of

systemctl start cloud-init.service

Ok, i found a solution that seems to work. If this is the way to go, SUSE broke the package. If not, I’m just too stupid to see the right way of doing it.

First disable all four services:

systemctl disable cloud-init.service cloud-final.service cloud-init-local.service cloud-config.service

Change one line in the following files:


And perform the following change:


Then, enable the services again. You will see, that they get symlinked into /etc/systemd/system/

systemctl enable cloud-init.service cloud-final.service cloud-init-local.service cloud-config.service

For thous who will search the answer.

  1. besides service and target files cloud init has its own generator that helps systemd to decide when to launch service.
  2. There are 2 documented cases when generator decided not to include cloud init in to boot goals even if service is enabled -
    But there is one more case - generator could not detect datasource. To change this behavior modify defaul cloud.cfg with your datasource or change generator config.
    Create file ds-identify.cfg with data:
policy: search,found=all,maybe=none,notfound=enabled

Dear or4uk,

This thread is more then three years old. The OP declared it as solved. Do you really think may people are still watching this?