Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

runtime-adapter: a_clone_refuses_a_scratch_image_whose_upper_an_earlier_clone_used fails intermittently

Closed
  • Is something wrong?
#1,020 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
linux, rust
Domain
infrastructure, operating-systems

Research direction

Start with tests/runtime-adapter/tests/vm_clone.rs, then trace graceful stop through nvx-rs/src/guest/root.rs and nvx-rs/src/guest/sys/port.rs. Check whether every stop path syncs or unmounts the scratch filesystem before power-off, including failures when another mount namespace holds the root. Done when graceful stop leaves a copied scratch image with its expected entries and the intermittent clone test passes.

Written by the indexing model from the issue text.

Description

a_clone_refuses_a_scratch_image_whose_upper_an_earlier_clone_used (tests/runtime-adapter/tests/vm_clone.rs) failed twice in CI on the Linux KVM runner (Guests and sandboxes), and passed on each rerun: run 40852461399 (attempt 1) and run 40943638955 (attempt 1). Both times the second start, over a copy of the earlier clone's scratch image, started (exit 0, sandbox=started) instead of ending with CLONE_FAILED (8) and unusable-root.

The guest's check_fresh (nvx-rs/src/guest/root.rs) accepts an upper whose upper and work directories are missing or empty. So the copy held none of the entries that the earlier clone wrote there: the overlay's work directory, and the file of the contents probe, which the test had checked reached the upper. Yet the test copied the image only after a stop that reported graceful, success 0 and complete.

Likely cause: the earlier clone's writes to the scratch's ext4 file system had not all reached the image when its VM powered off. ext4 commits its journal every 5 seconds by default, a clone reaches its probe and its stop within seconds, and the guest powers the VM off through the control port (power_off in nvx-rs/src/guest/sys/port.rs), which flushes nothing itself. To check:

  • whether the stop unmounts or syncs the scratch's file system before the power-off, on every path, and whether an unmount that fails (for example, while another mount namespace still holds the root) goes unreported;
  • if it does not, sync the scratch (syncfs) or unmount it before the power-off, so that a graceful stop leaves the scratch image complete. A scratch that is kept across boots needs the same.

Found in #957 (5102663a added the test), and seen again while validating stacked PRs on dev. Related to #833.

Dominant language
Rust
Stars
758
Forks
48
Avg merge
18h 27m
Merged PRs (30d)
446

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/nvx

All issues in microsoft/nvx

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.