build: move the upstream pkgs pin to libkrun 1.19.4 - #881

What moved

Two lines.

Why

The macOS side of the project has been on libkrun 1.19.4 for a while: vendor/libkrun/libkrun.lock
on main already reads

version=v1.19.4
commit=728df8125077d0db44265f6e997c72b81b65c015

and 728df8125077d0db44265f6e997c72b81b65c015 is what refs/tags/v1.19.4 resolves to in
containers/libkrun (verified via gh api repos/containers/libkrun/git/ref/tags/v1.19.4). It is also
the rpath commit baked into the shipped minvmd.

The package-served Linux path ([outputs.libkrun] → the upstream libkrun package →
scripts/fetch-libkrun.sh) was still resolving 1.19.0, because this repo's pkgs pin predated the
upstream bump. So the two halves of the project disagreed on which libkrun they were on. This closes
that gap; it does not change the macOS path at all.

Verification that the new pin actually resolves 1.19.4

packages/libkrun/build.ncl at c854d6b1e0fdc67efd84fc664251079c0719987d, read via
gh api repos/gominimal/pkgs/contents/packages/libkrun/build.ncl?ref=c854d6b1…:

let version = "1.19.4" in
{
  name = "libkrun",

  build_deps = [
    { file = "build.sh" } | Local,
    {
      url = "https://github.com/containers/libkrun/archive/refs/tags/v%{version}.tar.gz",
      sha256 = "e8775fab2b460972a67ca6cd936296bb79cdb078d852d712a283cb290dd0b284",
      extract = true,
      strip_prefix = "libkrun-%{version}",
    } | Source,

c854d6b1 is the pkgs commit that performed the bump
(gominimal/pkgs#459) — i.e. the oldest pkgs commit
that resolves 1.19.4. It was chosen deliberately over pkgs main, which is a further ~30 commits
ahead, to keep the blast radius as small as it can be while still getting 1.19.4.

This does NOT change vsock behaviour

Stating this explicitly because it is the obvious thing to assume and it is wrong.

gh api repos/containers/libkrun/compare/v1.19.0...v1.19.4 → 24 commits, 50 files changed, and
zero of those 50 filenames match vsock (case-insensitive). The delta is virtio-fs
(fs/device.rs, fs/server.rs, fs/worker.rs, both passthrough backends), cpuid transformers,
init_blob, the bundled edk2 firmware blob, Cargo.lock/Cargo.toml dep bumps, and upstream CI.
Nothing in libkrun's vsock device is touched, so this upgrade cannot fix, regress, or otherwise move
any vsock behaviour. Anyone chasing a vsock symptom should not treat this PR as a variable.

The include/libkrun.h diff over the same range is purely additive: a new krun_add_virtiofs4
plus two KRUN_SEMANTICS_* constants. No signature changes, no removals. Every symbol minvmd binds
(krun_create_ctx, krun_free_ctx, krun_set_vm_config, krun_set_root, krun_set_kernel,
krun_set_exec, krun_set_console_output, krun_add_disk2, krun_add_disk3,
krun_add_vsock_port, krun_add_vsock_port2) is unchanged.

What else the pin drags in

Moving the pin is not free — it pulls 22 pkgs commits (44 files). Reviewers are accepting all of
this, not just libkrun:

Version bumps (28 packages)

New packages (6): buddy, libsigsegv, libtecla, maude, tamarin-prover (+ an
fclabels-ghc910.patch) — the tamarin-prover addition from
gominimal/pkgs#449. Additive; nothing here depends on
them.

Non-version changes: zsh re-sourced from the gs:// mirror (its upstream URL rots when a
release moves to /pub/old/, gominimal/pkgs#450);
dune/build.sh gained an --auto-promote warm-up pass to work around dune's
generate_opam_files check; upstream pkgs CI got a disk-space step.

Assessment — read this bit. No toolchain package moves: base, base-bootstrap, toolchain,
gcc, glibc, rust, make, pkgconf are all untouched, so the compiler/libc floor under
everything is identical. The two entries worth a second look are:

• findutils 4.10.0 → 4.11.0 — in this repo's closure via [outputs.bash-img].
• libffi 3.6.0 → 3.7.1 — a low-level shared library, minor-version bump, in the closure of the
  Python-side packages.

Everything else is either a leaf CLI, a demo-profile package, or a package this repo does not build.
If a reviewer wants to be conservative, findutils and libffi are the two to think about; the rest
is noise.

Decision on the documented >= 1.19.0 floor: leave it where it is

I deliberately did not raise the documented floor to >= 1.19.4, and I want that on the record
rather than discovered later.

The >= 1.19.0 floor is not a restatement of what happens to be pinned — it is a claim backed by two
specific facts:

1. krun_add_disk3 (the /dev/vdb attach) first appears in 1.19.0.
2. 1.18.1's vsock device intermittently stalled a full session (multi-descriptor TX-chain bug).

Both are still exactly as true at 1.19.4 as they were at 1.19.0. Nothing we know of requires 1.19.4
specifically — as established above, the 1.19.0→1.19.4 delta doesn't even touch vsock. Bumping the
floor to match the pin would assert a requirement that no evidence supports, and would make the
scripts/build-libkrun-macos.sh assertion (which checks for the presence of krun_add_disk3, not a
version number) inconsistent with its own error message.

So: pinned version 1.19.4, documented floor >= 1.19.0. The only line changed is the one that
was a statement of fact about what is pinned and had become false. These floor statements were
inspected and deliberately left alone:

• crates/minvmd/README.md:229 — floor + the 1.18.1 bug history.
• crates/minimald/src/server.rs:382 — floor + the 1.18.1 bug history.
• crates/minvmd/tests/minimald_session_integration.rs:14,129,160 — floor in a doc comment, a panic
  message, and an #[ignore] reason.
• scripts/build-libkrun-macos.sh:84-87 — asserts nm -gU | grep _krun_add_disk3 and points the
  operator at vendor/libkrun/libkrun.lock on failure. It reads that lock (already v1.19.4) for
  version=/commit=; the >= 1.19.0 in its message is the API floor and remains correct.

Notes for a CODEOWNER

• No .github/workflows/ edit was needed and none was made (frozen, CODEOWNER-gated). I checked
  whether anything there went stale: ci-macos.yml:179 and :284, and the krun_add_disk3
  assertions in .github/actions/setup-libkrun-{linux,macos}/action.yml, all express the >= 1.19.0
  floor, which this PR intentionally preserves. Nothing under .github/ is stale as a result of
  this change — no follow-up needed.
• Possible textual conflict at merge. Other in-flight branches touch crates/minvmd/src/vm.rs
  and crates/minimald/src/server.rs. This PR does not touch vm.rs at all, and does not touch
  server.rs either (its >= 1.19.0 doc comment is a floor and was left alone), so the conflict
  surface is smaller than expected — but flagging it since the branches overlap in the same crates.
• Out of scope, noticed in passing, not touched: crates/minvmd/README.md:24 still advertises
  brew install slp/krun/libkrun, while scripts/build-libkrun-macos.sh's own header states that the
  third-party slp/krun tap is deliberately no longer in the supply chain. That line looks stale
  independently of this PR. Not fixed here — it is a different logical change.
• Spec decision records under docs/specs/02-spec-minvmd-linux-kvm/ and
  docs/specs/08-spec-vm-ext4-volume/ cite 1.19.0 as dated, verified-at-the-time findings
  ("verified against libkrun 1.19.0 header", "2026-07-07, libkrun 1.19.0"). Left untouched by
  design — editing them would falsify the record.

What I verified, and what I did not

Verified:

• packages/libkrun/build.ncl at the new pin reads let version = "1.19.4" (quoted above, fetched
  via gh api, not assumed).
• refs/tags/v1.19.4 in containers/libkrun = 728df8125077d0db44265f6e997c72b81b65c015, matching
  vendor/libkrun/libkrun.lock.
• c854d6b1 is 22 ahead / 0 behind 4538ab8b — a clean fast-forward, no divergence.
• Zero vsock-matching files in v1.19.0...v1.19.4; libkrun.h diff is additive only.
• No other file in this repo referenced the old pin hash (grep across the tree).
• .minimal/minimal.toml still parses and cargo test -p mfile is green (44 passed).
• cargo fmt --all --check — clean.
• cargo test -p minvmd — 129 passed, 0 failed, 6 ignored (the ignored ones are the
  MINVMD_E2E=1-gated boot/session/volume E2Es).
• cargo clippy -p minvmd --all-targets -- -D warnings — clean.

Not verified (and why):

• libkrun 1.19.4 was not actually built or booted from this pin. No min build, no VM boot, no
  minvmd rebuild/codesign — a live VM was mid-experiment on this machine and restarting it would
  have destroyed a measurement in progress. CI is the first place this pin gets exercised end to end.
• The sha256 in the new build.ncl was not independently recomputed against the upstream tarball;
  it is taken as correct from pkgs.
• cargo test --workspace was not run: macOS cannot build minimald (procfs). Pre-existing platform
  limitation, unrelated to this change. Test runs were scoped to minvmd and mfile accordingly.
• No runtime confirmation that the built 1.19.4 still exports krun_add_disk3 — but
  scripts/build-libkrun-macos.sh and both setup-libkrun-* composite actions assert exactly that in
  CI, and the header diff shows no removal.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Documentation
  • Updated the documented minimum required libkrun version for Linux end-to-end workflows to 1.19.4.
• Chores
  • Updated the pinned upstream revision used by the project configuration.