fix(cloud-init): correct service file typos in no-single-process.patch

[SeanDougherty]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

Corrects two typos in the cloud-init patch file, no-single-process.patch.

1. cloud-init.servic (truncated service name in cloud-config.target)

This appeared in the After= directive:

Wants=cloud-init-local.service cloud-init.service
After=cloud-init-local.service cloud-init.servic

systemd would attempt to reference a unit called cloud-init.servic, which doesn't exist.
Effects:

• cloud-config.target would not properly depend on or order after the cloud-init network stage (cloud-init.service)
• Services depending on cloud-config.target (like cloud-config.service and cloud-final.service) could start before the network stage completes, causing race conditions with network-dependent cloud-init modules
• systemd would log warnings about the unknown unit on every boot

2. journalconsole (invalid StandardOutput= value in cloud-init.service.tmpl)

journalconsole is not a valid systemd StandardOutput= value.
Effects:

• systemd would reject the directive and fall back to the default (inherit), or in some versions could fail to load the unit entirely
• Cloud-init network stage output would not appear on the instance serial/VM console, making it significantly harder to debug boot-time provisioning issues — especially in cloud/VM environments where the console log is often the only diagnostic channel

Combined impact:

The ordering typo was the more severe of the two — it broke the systemd dependency chain that ensures cloud-init stages run sequentially, potentially causing provisioning failures on first boot.

Change Log

• correct cloud-init.target's After= directive
• correct the StandardOutput= for the cloud-init.service template so it does not fallback to 'inherit'

Does this affect the toolchain?

NO

Test Methodology

in-prog