run-ephemeral: Use cloud-init=disabled instead of ds=None

[jeckersb]

Images with cloud-init installed ship a systemd drop-in
(disable-sshd-keygen-if-cloud-init-active.conf) that adds a condition
to sshd-keygen@.service preventing it from generating SSH host keys
when the cloud-init generator has activated cloud-init. The previous
ds=None kernel parameter caused the cloud-init generator to treat
'None' as a found datasource and create its activation symlink at
/run/systemd/generator.early/multi-user.target.wants/cloud-init.target.
This blocked sshd-keygen from generating host keys.

However, in the to-disk flow, cloud-init itself never actually ran
because the boot target (bcvk-to-disk.target) does not pull in
multi-user.target. The result was that neither sshd-keygen nor
cloud-init generated host keys, causing sshd to fail with 'no
hostkeys available', which in turn caused bcvk to-disk to time out
after 240 seconds waiting for SSH.

Using cloud-init=disabled instead causes the cloud-init generator to
not create the activation symlink at all, allowing sshd-keygen to
run normally and generate host keys.

Tested manually with a cloud-init-enabled bootc image; verified that
sshd-keygen runs, sshd starts successfully, and to-disk completes.

Assisted-by: AI
Signed-off-by: John Eckersberg dev@eckersberg.com

[jeckersb]

Man even with AI assistance this one took a while to run down

[cgwalters]

Ah so this was a regression from #370 right?

I think we could explicitly mask the generator with a /dev/null symlink in /run in addition/instead?

[jeckersb]

Man even with AI assistance this one took a while to run down

Ah so this was a regression from #370 right?

Yeah

I think we could explicitly mask the generator with a /dev/null symlink in /run in addition/instead?

Yeah that would also work I suppose, but this also seems to do the trick.