This document describes how to build and run avyos, along with available make options, testing, and debugging workflows.
For a system overview and code map, see
ARCHITECTURE.md.
You’ll need:
- Go (version as required by
go.mod) mksquashfs(SquashFS tools)cpio- QEMU (for
make run) - Optional:
wget(for CA bundle update)
Example (Debian/Ubuntu):
sudo apt-get update
sudo apt-get install -y golang-go squashfs-tools cpio qemu-system-x86 wgetBuild a bootable disk image:
makeRun it in QEMU:
make runBuild artifacts are created under:
_cache/<arch>/disk.img— bootable image_cache/<arch>/system.img— SquashFS OS core_cache/<arch>/initramfs.img— initramfs_cache/<arch>/variables— UEFI variables copy used by QEMU
Where <arch> is GOARCH (e.g. amd64, arm64).
Builds the bootable disk image.
Runs the built disk image in QEMU.
Removes generated images and build output under _cache.
Runs the documentation generator:
- output directory:
_cache/docsby default (override withDOCGEN_OUT)
Generates depends.<arch>.inc (dependency include file) used to improve incremental rebuilds.
Downloads a CA bundle to:
config/certificates/ca-certificates.crt
These variables can be passed on the command line:
make <target> VAR=value-
GO
Go command to use (default:go) -
GOFLAGS
Extra go build flags (default includes-tags netgo) -
GOARCH
Target architecture (default:go env GOARCH) -
RELEASE=1
Enables release-oriented Go flags:-buildvcs=false -trimpath -ldflags="-s -w -buildid="
-
KERNEL=linux(default)
Uses prebuilt kernel image:external/<arch>/kernel.img
-
KERNEL=<non-linux>
Builds the alternative kernel payload fromavyos.dev/kernelinto:_cache/<arch>/kernel.img
Notes:
- kernel build uses
GOOS=linux,CGO_ENABLED=0 DEBUG=1affects kernel GC/LDFLAGS (no optimizations; better for debugging)
-
CACHE_PATH
Root build cache directory (default:<repo>/_cache) -
DOCGEN_OUT
Output directory for docs (default:<CACHE_PATH>/docs)
-
QEMU
QEMU binary (auto-selected fromGOARCH) -
QEMU_ACCEL
Acceleration (auto):- Linux host:
-accel kvm - macOS host:
-accel hvf
- Linux host:
-
QEMU_VNC=1
Adds VNC output:-vnc :0 -
DBG_PORT(default: 5037)
Host port forwarded to the guest debug daemon (dbgd) port 5037. QEMU networking is configured as:hostfwd=tcp:127.0.0.1:<DBG_PORT>-:5037
DEBUG=1
Enables QEMU debug mode:- QEMU runs with
-s -S(waits for a debugger) - debug logging enabled (
_cache/<arch>/qemu-debug.log) - also enables kernel debug flags when using
KERNEL!=linux
- QEMU runs with
Basic run:
make runWith VNC:
QEMU_VNC=1 make runWith QEMU + kernel debug mode:
DEBUG=1 make runConsole selection:
amd64:console=ttyS0 console=tty0arm64:console=ttyAMA0,115200
avyos includes a remote debugging daemon service: dbgd.
- The daemon listens on guest TCP
:5037by default. - QEMU forwards that to your host at
127.0.0.1:${DBG_PORT}(default5037).
The repo provides a client at tools/dbg (host tool) to:
- run commands remotely
- open an authenticated shell
- pull files from the guest
- push files into the guest
Build and run the host client:
go run ./tools/dbg --helpThe client authenticates against dbgd using:
--user(default:admin)--passwordor environment variableDBG_PASSWORD- if neither is provided, it will prompt
Run a command (no shell parsing):
go run ./tools/dbg --host=127.0.0.1 --port=${DBG_PORT} cmd list /configRun a command using shell semantics:
go run ./tools/dbg --port=${DBG_PORT} shell "list /config | read pattern services"Download a file from the guest:
go run ./tools/dbg --port=${DBG_PORT} pull /config/init.conf ./init.confUpload a file to the guest:
go run ./tools/dbg --port=${DBG_PORT} push ./init.conf /config/init.confShow authenticated identity:
go run ./tools/dbg --port=${DBG_PORT} whoamiThe build includes Delve in the OS core at:
A typical flow:
- boot avyos (via
make run) - use the guest console or
dbg shellto rundlvagainst a target process or binary
Example (inside guest):
dlv exec /cmd/<tool>Depending on how you want to attach, you may need additional port forwarding or to run Delve in headless mode and forward its port via QEMU. This is a common approach for Go userspace debugging once the workflow is finalized.
Run unit tests on the host:
go test ./...Verbose:
go test -v ./...Because avyos includes OS-level behavior, many changes should also be validated by booting in QEMU and testing end-to-end behavior (service startup, IPC, UI, etc.).
There is no dedicated profiling target yet, but standard Go tooling works:
go test ./pkg/... -run TestName -cpuprofile cpu.out
go tool pprof cpu.outgo test ./... -bench . -benchmem -cpuprofile cpu.out -memprofile mem.out
go tool pprof cpu.out
go tool pprof mem.outFor runtime profiling of services/apps inside the guest, the preferred direction is to use:
- targeted instrumentation in the service/app, or
- a dedicated profiling service/tool exposed via Sutra, as the project evolves.
- If QEMU fails to boot, check:
_cache/<arch>/qemu-debug.log(whenDEBUG=1)- your
external/<arch>/firmware + kernel assets
- If
dbgcannot connect:- confirm QEMU is running with the default forwarded port (
DBG_PORT) - confirm
dbgdis running in the guest and listening on:5037
- confirm QEMU is running with the default forwarded port (