Skip to content

mkosi: "mkosi vm" fails because mkosi-sandbox wrapper breaks sandbox.main() __name__ guard #510068

@anadon

Description

@anadon

Nixpkgs version

  • Unstable (26.05)

Describe the bug

Every mkosi subcommand that spawns a helper through mkosi-sandbox fails with:

ValueError: A command line to execute can only be provided if mkosi.sandbox is executed

Affected subcommands include mkosi vm (fatal — spawns virtiofsd as its first post-qemu step), mkosi journalctl, and mkosi shell.

Root cause: pkgs/by-name/mk/mkosi/package.nix builds with buildPythonApplication, which generates $out/bin/mkosi-sandbox from mkosi's pyproject.toml [project.scripts] declaration. The generated wrapper does:

from mkosi.sandbox import main
if __name__ == "__main__":
    sys.exit(main())

At call time, mkosi.sandbox.__name__ is "mkosi.sandbox" (the module's own name), not "__main__". Inside mkosi/sandbox.py, the main() function guards against accidental import-time argument parsing with an is_main() check that returns False in this case. When invoked with a real command line — which is exactly what mkosi vm does every time it spawns virtiofsd — the guard raises, the subprocess exits non-zero, and the parent mkosi vm invocation aborts.

Steps to reproduce

Run the following in an empty directory. Requires Nix on the host with network access. A bundled reproducer script lives at docs/upstream-reports/reproducers/N1-sandbox-wrapper.sh in the reporter's tree, but the minimal inline form below stands alone:

tmp=$(mktemp -d) && cd "$tmp"
cat > mkosi.conf <<'EOF'
[Distribution]
Distribution=fedora
Release=40
RepositoryKeyFetch=yes

[Output]
Format=disk

[Content]
Bootable=yes
Bootloader=uki
Packages=systemd systemd-udev systemd-boot-unsigned kernel bash coreutils util-linux dosfstools
EOF

nix-shell -p mkosi-full --run 'mkosi -f build 2>/dev/null || true; mkosi vm'
# => ValueError: A command line to execute can only be provided if mkosi.sandbox is executed

Note: the mkosi -f build step may itself fail on a separate packaging issue (narrow chroot PATH; filed separately). The mkosi vm failure reproduces regardless of whether the build succeeded, because virtiofsd-spawn happens at vm launch before anything else.

Expected behaviour

mkosi vm spawns virtiofsd via the helper and proceeds to boot the image. mkosi's is_main() guard is intended to reject accidental import-time argument parsing, not to reject CLI invocations of the packaged mkosi-sandbox binary.

Screenshots

No response

Relevant log output

Additional context

Add a postFixup to pkgs/by-name/mk/mkosi/package.nix that rewrites $out/bin/.mkosi-sandbox-wrapped so the module body runs under __name__ == "__main__":

postFixup = (old.postFixup or "") + ''
  wrapper="$out/bin/.mkosi-sandbox-wrapped"
  if [ -f "$wrapper" ]; then
    ${python3}/bin/python3 - "$wrapper" <<'PYEOF'
  import pathlib, re, sys
  p = pathlib.Path(sys.argv[1])
  t = p.read_text()
  t = re.sub(
      r"import re\nimport sys\nfrom mkosi\.sandbox import main\n.*",
      ("import runpy\n"
       "runpy.run_module('mkosi.sandbox', run_name='__main__', alter_sys=True)\n"),
      t, count=1, flags=re.DOTALL)
  p.write_text(t)
  PYEOF
  fi
'';

The trampoline preserves the site.addsitedir preamble already in the generated wrapper (which injects rpm and createrepo_c Python bindings) and only replaces the entry-point body. Verified to make mkosi vm complete successfully on NixOS 25.11 with kernel 6.14 + KVM.

A complementary upstream fix — relaxing is_main() so mkosi-sandbox works whether invoked as __main__ or imported — will be filed at systemd/mkosi as a separate issue; either fix alone is sufficient.

System metadata

  • system: "x86_64-linux"
  • host os: Linux 6.19.9, NixOS, 26.05 (Yarara), 26.05pre969196.46db2e09e1d3
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.31.3
  • channels(root): "agenix, home-manager, nixos, nixos-hardware"
  • nixpkgs: /nix/store/ha66nqxl4sx8smvp63hrq6gwjiwvlzwl-nixos/nixos

Notify maintainers

@malt3 @msanft

I assert that this issue is relevant for Nixpkgs

Is this issue important to you?

Add a 👍 reaction to issues you find important.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions