Populating an ext4 image from a tarball is a runtime dlopen of
libarchive in mke2fs, not a linked dependency: the deb does not pull
it in, the stage set did not have it, and the first snap build failed
with "you need libarchive to be able to process tarballs". Stage
libarchive13t64 next to e2fsprogs.
The rootfs boots from a virtio-blk disk now, and the blk feature is
what compiles the device into libkrun - without it krun_add_disk and
krun_set_root_disk_remount have no symbols and every run fails at
lookup. e2fsprogs joins the stage set for mkfs.ext4 (the cache image
build) and debugfs (per-run provisioning and the control-file read);
core26 ships 1.47.4, which knows how to build from a compressed
tarball.
The summary takes the README tagline. The description now leads with
an Install section, shows a first run that opens a shell, and leaves
the XDG redirection internals out of the listing.
The version: key in snapcraft.yaml was a second number to bump by
hand, and between releases it read whatever it was left at. The ecrou
part now sets its version from [workspace.package] at pull time —
the same value clap reports with --version — so Cargo.toml is the
only place a version lives, and the release workflow stamps only
that. A missed match fails the pack loudly.
The pack lint flagged five empty metadata fields. They render on the
snapcraft.io listing, and contact is asked for at publish time. The
repo answers for website, source-code, and contact (the issue tracker,
since the listing is public); title matches the binary name.
libkrunfw5 ships for riscv64 in ubuntu-ports, not the main archive
(archive.ubuntu.com carries amd64 and arm64 binaries); the part now
maps each target arch to its pool and a pinned digest.
The pool carries an arm64 libkrunfw5 next to the amd64 one, so the
part now picks the flavor and the install path from the target arch
(CRAFT_ARCH_BUILD_FOR / CRAFT_ARCH_TRIPLET_BUILD_FOR) with the
checksum pinned per arch. riscv64 goes: the pool has no libkrunfw5
build for it, and libkrun does not target it.
Config::load was never called: the DNS-override story it carried
contradicts the actual resolver flow, and nothing in the CLI or
snap advertised a key. Delete the module and every mention of the
ecrou.yaml file in SPEC and the snap; the XDG_CONFIG_HOME redirect
in the command chain served only that file.
The description carried a confinement section SPEC.md already owns,
and the part comments narrated build steps the commands state on
their own. First run now shows a plain run instead of the microVM
proof.
The run interface read like a library's. `ecrou run -it alpine` now
hands the guest a terminal: with no console output file, libkrun wires
the guest console to the process's own stdio and raw-modes the tty.
The parent saves and restores the termios around the run, because
libkrun's own restore lives in the child's exit observers, which a
SIGKILLed machine never runs. A tty run refuses to start without a
terminal on stdin and stdout, and --capture refuses to combine with
-t: the payload's streams cannot land in files and on the terminal at
once.
-i without -t keeps the machine's stdin open through pipes: libkrun
exposes the non-tty streams as virtio console ports (krun-stdin,
krun-stdout, krun-stderr), and the guest init points the payload's
stdio at whichever port nodes exist. `echo hi | ecrou run -i alpine --
cat` crosses the machine; a stream the host left on a tty has no port
node and stays on the console.
-v (--volume HOST:GUEST[:ro]) replaces --share, and -w aliases
--workdir. The global -v/--verbose loses its short flag to make room;
verbose stays reachable by its long form.
A reference starting with ./, ../ or / names a local rootfs archive:
read in place on every run, never downloaded, never cached as a
pristine entry. Provisioning over one persists into a derived cache
entry keyed by size and mtime, so the caller's file is never
overwritten and an edited archive lands in a fresh entry.
core26 base, strict confinement, the kvm interface for acceleration
with home and network auto-connected. The runtime needs nothing else:
the host process never mounts a filesystem and never creates or
enters a namespace, so it already lives inside snapd's default-deny
seccomp allowlist. The built .snap artifact is ignored.
vhaudiquet