Files
c630/docs/runner-setup.md
rob thijssen 280874f564 Build Fedora aarch64 images for the Lenovo Yoga C630
Assembles a ready-to-write disk image via Gitea Actions. Mainline has carried
sdm850-lenovo-yoga-c630.dts since 5.5 and Fedora ships it in kernel-core, so
unlike aarch64-laptops/build there is no kernel or GRUB to compile — what is
left is producing an image that boots on firmware which hands Linux no device
tree.

The build runs in an aarch64 container under qemu-user and builds filesystems
from directory trees with mke2fs -d and mcopy rather than mounting loop
devices, so it works on runners that will not hand out /dev/loop-control.

A kernel-install hook writes the devicetree line into each BLS entry; without
it the first `dnf update kernel` would produce an unbootable system.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
2026-07-27 11:24:53 +03:00

2.1 KiB
Raw Blame History

Gitea runner setup

The build runs on runners labelled metal, executing directly on the host rather than in a runner-provided container, because it needs to drive podman itself.

One-time host preparation

On each runner host:

sudo dnf install -y podman qemu-user-static-aarch64
sudo systemctl restart systemd-binfmt

Verify:

cat /proc/sys/fs/binfmt_misc/qemu-aarch64

The flags: line must contain F. That flag makes the kernel open the interpreter at registration time and keep the reference, so qemu-aarch64-static resolves even inside a container that does not have it. Without it, every aarch64 binary inside the build container fails with exec format error. qemu-user-static-aarch64 registers it correctly; plain qemu-user does not.

The workflow attempts this install itself, but that only works if the runner account has passwordless sudo. Run probe-runner.yaml to find out.

Checking what a runner can do

The probe runner workflow is manual-dispatch only and reports architecture, user, sudo, podman, emulation status and free disk. Run it once per runner before debugging a build failure.

Disk space

The build stages a full root filesystem and three filesystem images alongside the final disk image, under the job workspace. Budget roughly:

  • minimal — about 20 GiB
  • workstation — about 45 GiB

Runtime

Every aarch64 binary runs under qemu-user emulation, and rpm scriptlets are the worst case. Expect roughly 4590 minutes for minimal and several hours for workstation. The workflow's timeout-minutes is set to 600 accordingly.

If this becomes tiresome, the fix is a native aarch64 runner. Register one with an aarch64 label and change runs-on: metal to runs-on: aarch64 in .gitea/workflows/build-image.yaml; build/build-image.sh already skips the emulation check when the host is already the target architecture.

Changing which runners are used

All nine current runners carry metal and podman. runs-on: metal therefore matches any of them. To pin the build to a subset, give those runners a distinct label and use it — Gitea requires a runner to carry every label listed in runs-on.