Skip to content

fix: ask cloud-init whether a machine booted as root - #65

Merged
riadelhajjaji-scality merged 1 commit into
mainfrom
bugfix/wait-for-boot-cloud-init-as-root
Nov 2, 2026
Merged

riadelhajjaji-scality merged 1 commit into
mainfrom
bugfix/wait-for-boot-cloud-init-as-root

Conversation

@riadelhajjaji-scality

Copy link
Copy Markdown
Contributor

Updating a platform waits again on every machine, the ones left alone included. On a Rocky machine where anything installed a package since it booted, cloud-init status failed as the SSH user with a PermissionError on /run/cloud-init/cloud.cfg, so the update failed with "booted badly, cloud-init exited 1". This breaks the MetalK8s bootstrap-restore nightly at "Destroy the Bootstrap node" every night since it moved to platform-spawner (e.g. https://github.com/scality/metalk8s/actions/runs/40701329682).

The cloud-init package keeps /run/cloud-init to root through a tmpfiles rule (d /run/cloud-init 0700 root root), and the systemd package runs every tmpfiles rule again whenever a package ships one (%transfiletriggerin -- /usr/lib/tmpfiles.d → systemd-tmpfiles --create). cloud-init then cannot read its own runtime config for anybody else (canonical/cloud-init#6680). Freshly booted machines do not show it, which is why spawns, and the update test here where nothing gets installed, went through. In the failing run the bastion passed the same check a second before node-2 failed it.

The status is now asked through sudo -n, which the SSH users of the images have, and which fails rather than waits on a password.

@riadelhajjaji-scality

Copy link
Copy Markdown
Contributor Author

Replaced by #66

@riadelhajjaji-scality

Copy link
Copy Markdown
Contributor Author

@TeddyAndrieux I reopened this PR because it is now being used alongside #5818 (https://github.com/scality/artesca/pull/5818) to test the CI bug that this PR was meant to fix

Comment thread __main__.py Resolved
Updating a platform waits again on every machine, the ones left alone
included. On a Rocky machine where anything installed a package since
it booted, `cloud-init status` failed as the SSH user with a
PermissionError on /run/cloud-init/cloud.cfg, so the update failed
with "booted badly, cloud-init exited 1".

The cloud-init package keeps /run/cloud-init to root through a
tmpfiles rule, and the systemd package runs every tmpfiles rule again
whenever a package ships one. cloud-init then cannot read its own
runtime config for anybody else (canonical/cloud-init#6680). Freshly
booted machines did not show it, which is why spawns, and updates of
platforms nothing was installed on, went through.

The status is now asked through `sudo -n`, which the SSH users of the
images have, and which fails rather than waits on a password.
@riadelhajjaji-scality
riadelhajjaji-scality force-pushed the bugfix/wait-for-boot-cloud-init-as-root branch from 4ac5657 to 43eda45 Compare November 2, 2026 12:31
@riadelhajjaji-scality
riadelhajjaji-scality merged commit b8c433e into main Nov 2, 2026
14 checks passed
@riadelhajjaji-scality
riadelhajjaji-scality deleted the bugfix/wait-for-boot-cloud-init-as-root branch November 2, 2026 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants