feat/virtiofs-mount-mode
CI / build (pull_request) Failing after 8s
Adds a boot flag choosing how virtiofsd is launched per --mount: - unshare (default, previous behavior): virtiofsd runs inside 'podman unshare' with --sandbox chroot, mapping guest UIDs into the invoking user's subuid range. - direct: virtiofsd runs as the invoking user with --sandbox none, mapping guest UIDs 1:1 to host UIDs. The direct mode is needed when the shared directory itself lives on a virtiofs/fuse mount that rejects subuid-range UIDs (e.g. nested boco): guest writes through the subuid mapping then fail with EINVAL, breaking anything that writes to shares as a non-root guest user (databases, agent workspaces). Direct mode also cannot use the chroot sandbox (unprivileged chroot() is not permitted), so it falls back to --sandbox none; served trees are then not symlink-escape-protected. Verified both modes boot and serve mounts (alpine guest).
boco
Turn container images into bootable VMs
Example
# ./example/alpine/Containerfile
FROM alpine:latest
CMD ["/bin/sh"]
# Build the container
podman build ./example/alpine -t boco-alpine
# Make the container bootable. boco injects a custom init program,
# then packs the rootfs as a qcow2 disk.
boco build qcow2 boco-alpine
# Boot the image using QEMU, and drop into /bin/sh.
boco boot boco-alpine
# Cleanup
boco image rm boco-alpine
podman image rm boco-alpine
Can also be used to boot a more traditional systemd-based VM:
FROM archlinux:latest
# This works! Although you should probably add a user or some services.
CMD ["/sbin/init"]
Kernel
boco boots VMs using a shared kernel at $XDG_DATA_HOME/boco/registry/vmlinuz.
Place a suitable x86 bzImage there before running boco boot.
Languages
Rust
78.6%
Shell
21.3%
Dockerfile
0.1%