ds-identify runs too early

This bug was originally filed in Launchpad as [LP: #1810859](https://bugs.launchpad.net/cloud-init/+bug/1810859)

Launchpad details

affected_projects = []

assignee = None

assignee_name = None

date_closed = None

date_created = 2019-01-07T22:08:22.649513+00:00

date_fix_committed = None

date_fix_released = None

id = 1810859

importance = medium

is_complete = False

lp_url = https://bugs.launchpad.net/cloud-init/+bug/1810859

milestone = None

owner = rjschwei

owner_name = Robert Schweikert

private = False

status = triaged

submitter = rjschwei

submitter_name = Robert Schweikert

tags = []

duplicates = []

_Launchpad user **Robert Schweikert(rjschwei)** wrote on 2019-01-07T22:08:22.649513+00:00_

ds-identify is executed from a systemd generator [1]. Based on my understanding of the intention of both this creates a non resolvable timing conflict.

Generators run very early in the boot process.

The cloud-init generator runs ds-identify which in turn runs "blkid" to find filesystems with specific labels, "cidata" for the nocloud data source. However, it is possible to construct an environment where the filesystem with the "cidata" label is on an attached device and the generator runs prior to the attached device being known to the kernel and thus the return of blkid cannot reflect the proper status, meaning the "cidata" label cannot be found and thus the "nocloud" data source is not properly identified. This implies that the cloud-init.target unit will be disabled.

Observed in a test environment with qemu and the data source on a separate virtual device.

According to [1] we shouldn't add any sync points such as "udevadm settle", thus I am not certain how this could be resolved. Also given that we cannot control the timing of the execution of the generator it appears that this is going to be difficult to get under control.

Would it make sense to give ds-identify the option to simply exit and leave things alone?

In the present setup the generator target runs ds-identify which in turn will disable cloud-init.target if no data source can be identified. However, the Python code usually runs late enough that things that are no available in early boot are found and data sources are identified properly. If users that know they run in a specific environment could set a "ds=no-check" flag on the kernel command line then the timing issue could be prevented.

I realize for the nocloud case a user can set "ds=nocloud" on the kernel command line to work around the timing issue described herein. Also a "ds=no-check" would circumvent the basic intention of the generator to allow cloud-init to be installed anywhere and simply detect quickly an environment where cloud-init Python code should not be executed and thus safe boot time.

My point is that, IMHO, timing issues in general cannot be avoided by ds-identify due to the nature of when systemd executes the generators. Thus giving users the general ability to disable ds-identify maybe useful.

I am happy if I can be proven incorrect and the timing issue can be resolved.

[1] https://www.freedesktop.org/wiki/Software/systemd/Generators/