Skip to content

Test against the kernel the shipped tool installs, and stop the reaper eating the rootfs - #863

Open
MayCXC wants to merge 3 commits into
apple:mainfrom
MayCXC:integration-suite-setup
Open

Test against the kernel the shipped tool installs, and stop the reaper eating the rootfs#863
MayCXC wants to merge 3 commits into
apple:mainfrom
MayCXC:integration-suite-setup

Conversation

@MayCXC

@MayCXC MayCXC commented Aug 27, 2026

Copy link
Copy Markdown

Summary

Three things the integration suite needs before anything builds on it.

The kernel the tests fetch had drifted from the one users run. container installs kata 3.28.0 and its 6.18.15 kernel while these tests fetched 3.17.0, so the suite exercised a guest with a different feature set to the one it represents. Nested runtimes are the visible case: 3.17.0 was built without nf_tables, so a docker daemon inside a container fails there and works on what ships. Kata moved from xz to zstd between those releases, so the archive is no longer named for its compression, and tar is left to recognise it rather than being told, which also holds if the format changes again.

The reaper deleted the rootfs it meant to preserve. Running at a concurrency of one, it deletes everything in the test directory except the unpacked rootfs. It held that path as FileManager reports it, under /var, and compared it against contentsOfDirectory entries, which come back under /private/var, so the preserved path never matched and the rootfs went with the per-test files. The unpack coordinator still held it as unpacked, so the next test opened a rootfs that was no longer there. Both sides now resolve with resolvingSymlinksInPathWithPrivate, which exists for exactly this difference between two views of one directory.

make test says nothing about what it skipped. Tests guarded for Linux are compiled out on macOS, so the target reports success without running them, and the target that does run them is mentioned nowhere outside the makefile.

Motivation and Context

These are separable but all in the same area, and each is the kind of thing that makes a later failure hard to read: a guest with the wrong feature set, a test that fails because a previous test's cleanup removed its rootfs, and a green run that skipped what you cared about.

No issue filed, as this touches only the test suite and its docs and carries no user-visible behaviour. Happy to open one if the project prefers it recorded.

Testing

  • swift build and make check clean.
  • swift test: 603 tests in 83 suites passed.
  • Integration suite runs against the kata release the config names, and the reaper no longer removes the shared rootfs between tests.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

MayCXC added 3 commits August 27, 2026 20:43
The reaper that runs at a concurrency of one deletes everything in the
test directory except the unpacked rootfs it means to preserve. It held
that rootfs path as FileManager reports it, under /var, and compared it
against the entries of contentsOfDirectory, which reports them under
/private/var, so the preserved path never matched any entry and the
rootfs was deleted along with the per-test files. The unpack coordinator
still held it as unpacked, so the next test opened a rootfs that was no
longer there and failed with a missing file error.

Resolve both sides with resolvingSymlinksInPathWithPrivate, which exists
for this difference between the two views of the same directory.
Tests guarded for Linux are compiled out on macOS, so `make test` reports
success without having run them, and nothing says so. The target that
does run them is not mentioned anywhere outside the makefile.
The default kernel the tests fetch had drifted from the one users run.
container installs kata 3.28.0 and its 6.18.15 kernel, while these tests
fetched 3.17.0, so the suite exercised a guest with a different feature
set to the one it is meant to represent. Nested runtimes are the visible
case: 3.17.0 was built without nf_tables, so a docker daemon inside a
container fails there and works on what ships.

Kata moved from xz to zstd between those releases, so the archive is no
longer named for its compression and tar is left to recognise it rather
than being told, which also holds if the format changes again.
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.

1 participant