manifold-cc: fix gatekeeper failing tests - #532
Draft
Saul Paredes (Redent0r) wants to merge 7 commits into
Draft
Conversation
Saul Paredes (Redent0r)
changed the title
Aurélien Bombo (sprt)
self-requested a review
August 21, 2026 18:34
USE_BUIDIN_DB -> USE_BUILTIN_DB So we can disable dragonball as expected. Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
The erofs jobs on this branch fail at "Deploy Kata" with nothing to go on: kata-deploy reconfigures the CRI and restarts containerd as part of its install, so once that restart goes wrong the node's CRI is dead and `kubectl logs` only ever answers "unable to retrieve container logs". The pod describe that we do capture is stale as well, because kubelet can no longer update the pod status. Collect the evidence from the node instead. Snapshot /etc/containerd/config.toml and the erofs host prerequisites before the deploy, and on any of the three deploy failure paths dump the kata-deploy container logs straight from /var/log/pods (kubelet writes them to the host, so they survive a dead containerd), the containerd unit state and journal scoped to the deploy, `containerd config dump` (which loads and validates the on-disk config), a diff of the containerd config against the pre-deploy snapshot, the kubelet journal, and the erofs host state again. Finally map the collected evidence onto the commits that introduced each failure mode, so the run names the change to revert instead of leaving it to inspection. Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
d607cce ("EROFS verity: declare the block size, pin the differ, fail closed (RM-47/48/50)") started writing an array of inline tables: unpack_config = [{platform = "linux/amd64", snapshotter = "erofs", differ = "erofs"}, ...] set_toml_value could not represent that. Its value parser handled arrays by splitting on commas and pushing every piece as a string, which is fine for ["erofs","walking"] but turns the unpack config into unpack_config = ['{platform = "linux/amd64', 'snapshotter = "erofs', ...] Still valid TOML, so nothing on our side complained - but containerd refuses to start with toml: cannot decode TOML string into struct field transfer.transferConfig.UnpackConfiguration of type []transfer.unpackConfiguration and since we write this drop-in and then restart containerd, the node loses its CRI for good: kubelet can no longer probe, restart or even fetch logs for the kata-deploy pod, and the erofs jobs time out at "Deploy Kata" with no usable output. Hand the value to toml_edit instead and fall back to a bare string only when it is not standalone TOML, so composite values round-trip as themselves. The existing erofs_unpack_config test parses the string directly and never goes through set_toml_value, so cover the round-trip here, together with the scalar and string-array forms every other caller relies on. Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
The dm-verity rule matched any mention of dmverity, and containerd's own config dump always contains dmverity_mode, so every failure was reported as a dm-verity suspect on top of the real one. Match the messages that only appear when dm-verity actually fails instead. Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
d607cce ("EROFS verity: declare the block size, pin the differ, fail closed (RM-47/48/50)") writes an unpack_config listing only the erofs snapshotter. That key replaces containerd's built-in default rather than extending it, and getSupportedPlatform() in core/transfer/local/pull.go only accepts an entry whose snapshotter equals the one the pull asked for. So every pull that does not ask for erofs matches nothing, the unpacker is built with an empty platform list, and the pull fails with unable to initialize unpacker: no unpack platforms defined Since we also set use_local_image_pull = false, every CRI pull goes through the transfer service, so this takes down image pulls node-wide - the erofs k8s jobs fail it on each test. Restate containerd's default entry next to the erofs binding. An erofs pull still goes through the erofs differ, which is all RM-50 asked for, and everything else pulls the way it did before kata-deploy touched the config. Ordering is safe: a match requires the snapshotter to be equal, and a pull that omits it explicitly prefers the default snapshotter entry. Assisted-by: GitHub Copilot (Claude) Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
Saul Paredes (Redent0r)
force-pushed
the
saul/fix-manifold-cc-ci
branch
from
August 31, 2026 17:45
8f49f37 to
1dfd3f0
Compare
kubeadm 1.37 dropped the kubeadm.k8s.io/v1beta3 API, so `kubeadm init` now refuses the config we hand it, with: ``` error: your configuration file uses an old API spec: "kubeadm.k8s.io/v1beta3" (kind: "ClusterConfiguration"). Please use kubeadm v1.36 instead and run 'kubeadm config migrate ...' ``` That takes down the whole vanilla k8s deployment: without a cluster there is no /etc/kubernetes/admin.conf to copy, so every kubectl call that follows falls back to localhost:8080 and fails as well. Retrying does not help either, as the config is rejected the same way on each attempt. Move both documents to v1beta4, which needs no other change as the fields we set are untouched. This is safe for the versions we install, which are the latest minor and the one before it, as v1beta4 has been supported since kubeadm 1.31. While here, spell the CRI socket as a unix:// URL, which is the form the v1beta4 documentation uses. A bare absolute path is still accepted, but only through a deprecation path we have no reason to rely on. Assisted-by: Cursor <cursoragent@cursor.com> Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com> (cherry picked from commit 83dd527)
The kata-agent-apis job fails four of its twelve tests:
not ok 1 Test CopyFile API: Copy a file to /run/kata-containers
not ok 2 Test CopyFile API: Copy a symlink to /run/kata-containers
not ok 3 Test CopyFile API: Copy a directory to /run/kata-containers
not ok 5 Test CopyFile API: Copy a large file to /run/kata-containers
each with
removing "/run/kata-containers/shared/containers/" prefix from
/run/kata-containers/foo: prefix not found
do_copy_file() confines writes to the guest share directory, so a
destination directly under /run/kata-containers is refused. The tests still
use the pre-confinement paths, one level above the share directory, and
only the test asserting a rejection still passes.
The confinement comes from upstream 3dba12c ("agent: constrain copy_file
to shared directory"), which updated the agent and these tests together. We
carry the agent half but not the test half, so take the test half verbatim
from that commit: retarget the four destinations, and pick up the
regression test that pins /run/kata-containers/shared as still refused.
Assisted-by: GitHub Copilot (Claude)
Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.