ds-identify fails on nocloud datasource when /var is a separate filesystem

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1884949

Launchpad details

affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2020-06-24T14:10:35.725425+00:00
date_fix_committed = None
date_fix_released = None
id = 1884949
importance = low
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1884949
milestone = None
owner = mdrangula
owner_name = Mike Drangula
private = False
status = triaged
submitter = mdrangula
submitter_name = Mike Drangula
tags = []
duplicates = []

Launchpad user Mike Drangula(mdrangula) wrote on 2020-06-24T14:10:35.725425+00:00

I'm running CentOS 7.8.2003 with cloud-init 18.5. At least in CentOS, systemd is running the generators, including the cloud-init generator, before any secondary filesystems are mounted.

Thus, in ds-identify/dscheck_NoCloud/check_seed_dir, this line of code is invalid:

local dir="${PATH_VAR_LIB_CLOUD}/seed/$name"
[ -d "$dir" ] || return 1

because PATH_VAR_LIB_CLOUD is set to /var/lib/cloud and when this code is running /var is not yet mounted.

I'm sorry but I am not setup to test using a more recent version of cloud-init.

[ubuntu-server-builder]

Launchpad user Dan Watkins(oddbloke) wrote on 2020-06-30T14:36:02.351787+00:00

Hi Mike,

Thanks for the bug report!

I just want to make sure I understand the issue: you've written some seed configuration into /var/lib/cloud/seed/nocloud (or nocloud-net), and instead of applying the configuration, cloud-init instead doesn't run at all (because the generator doesn't detect the seed directory). Is that correct?

How does /var end up as a separate partition? Are you launching generic cloud images which have this configuration, or are these images you've mastered yourself?

(Once you've answered these questions, please move the bug report back to New.)

Thanks!

Dan

[ubuntu-server-builder]

Launchpad user Mike Drangula(mdrangula) wrote on 2020-06-30T15:35:06.081177+00:00

Correct. I've written a seed configuration into /var/lib/cloud/seed/nocloud but cloud-init never runs, because the generator does not detect the seed directory.

/var is a separate partition because I have created an image laid out that way. This was done to meet CIS guidelines.

[ubuntu-server-builder]

Launchpad user Paride Legovini(paride) wrote on 2020-07-03T11:20:29.341896+00:00

Hi Mike,

In my understanding this shouldn't happen as cloud-init-local.service contains:

RequiresMountsFor=/var/lib/cloud

[Install] WantedBy=cloud-init.target

The RequiresMountsFor option should add a dependency on the var.mount unit. Could you please try running:

systemctl list-dependencies cloud-init

and paste or attach the resulting tree to this bug? Is the var.mount unit present and working on your system?

Again, please move the bug status back to New after replying. Thanks!

[ubuntu-server-builder]

Launchpad user Dan Watkins(oddbloke) wrote on 2020-07-03T13:27:45.682372+00:00

In my understanding this shouldn't happen as cloud-init-local.service contains:

I don't think this quite follows: the issue is that the generator doesn't enable cloud-init-local.service because the seed directory isn't present at generator time.

/var is a separate partition because I have created an image laid out that way.

In that case, you could also consider writing explicit cloud-init configuration so the generator doesn't disable it; writing this to /etc/cloud/cloud.cfg.d/99_some_sensible_name.cfg:

datasource_list: [ NoCloud ]

should do it.

[ubuntu-server-builder]

Launchpad user Paride Legovini(paride) wrote on 2020-07-07T13:37:27.856680+00:00

Right, thanks Dan!

I'm marking this as Triaged as I think the problem is fully understood, but I don't have a sensible proposal for a solution.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-07-07T15:31:42.953272+00:00

A lot of this is a limitation of the generator, due in part to implementation language. I'm not sure the best path to fix it.

One workaround that might work for Mike is to seed NoCloud via /etc/cloud/your-seed.cfg

You can currently only put user-data and meta-data (no vendor-data or network-data) there, but something like this should work:

datasource: NoCloud: user-data: | # this is user-data verbtum meta-data: instance-id: i-abcdefg local-hostname: foo.bar

See for more info at

https://github.com/canonical/cloud-init/blob/master/doc/examples/cloud-config-datasources.txt#L30

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2020-07-07T15:32:21.541633+00:00

I think it would be sane to support vendor-data and network-data in that same format.