Repository navigation
tools.lock: arm64 binaries; install-tool.sh picks the runner's architecture - #32
Merged
Merged
Conversation
…ecture Every tool gets a <name>/arm64 line at its version, with the sha256 of the release asset. install-tool.sh takes that line on an arm64 runner (ubuntu-24.04-arm) and the plain line on x86_64, and installs the binary under its usual name. Before, an arm64 runner got x86_64 binaries, so the shell gate's build-runs-on: ubuntu-24.04-arm could not run its recipes. scripts/test_tools_lock.sh checks the lock: five fields, a sha256, https, and both architectures at the same version. The self-test installs every tool on an arm64 runner and runs it, and runs the shell gate's build there.
markope
added a commit
to IronFlock/ironflockos
that referenced
this pull request
Nov 5, 2026
CI's matrix is now target and variant: amd64-efi base and nvidia on x86 runners, arm64-efi base on arm64 runners (NVIDIA's repositories of the nvidia variant are x86_64 only, and mkrootfs refuses it elsewhere). The rootfs package list is the base profile, the target's packages and the variant's. IronFlock/workflows#32 is published as v1.4.4: the build and rootfs-scan jobs check out the harness at v1 again.
markope
added a commit
to IronFlock/ironflockos
that referenced
this pull request
Nov 5, 2026
…m64 runners (#161) WP-7.1: the `arm64-efi` target for generic arm64 machines with UEFI: SystemReady edge boxes, Ampere servers and arm64 VMs. CI builds it natively and boots it in QEMU on GitHub's arm64 runner. **Depends on IronFlock/workflows#32.** That PR adds arm64 tools to the harness. Until it is published, the two jobs here that install harness tools on arm64 check the harness out at that PR's commit. Once v1 includes it, both go back to `ref: v1`. **Builds on #159 (provisioning).** Until #159 merges, the diff here includes it. ## The target - **Shared EFI files:** `targets/arm64-efi` is amd64-efi with the architecture swapped. The boot script, RAUC `system.conf`, genimage layout and `repart.d` are amd64-efi's files, as symlinks, so the two EFI targets keep one A/B scheme. The rt kernel's boot-script change in #157 reaches arm64-efi through the same file. - **Boot:** GRUB's arm64-efi image is `EFI/BOOT/BOOTAA64.EFI`. The slots use the root-arm64 partition type. The console is the PL011 (`ttyAMA0`) and the screen. GRUB uses the firmware's serial port (`serial efi0`). - **Packages:** each target now brings its kernel in `targets/<target>/packages`, which mkrootfs reads after the base lists. Debian's arm64 kernel and `grub-common` moved there from `profiles/base/packages.arm64`, and the same for amd64. The Raspberry Pi and Jetson targets bring other kernels and no GRUB. ## The QEMU test on arm64 - **Machine:** QEMU's `virt` machine with AAVMF. virt has one UART, so the test shell runs on a virtio console (`hvc0`). The test copy's command line masks the getty that systemd starts there by itself. - **No KVM:** GitHub's arm64 runners have none, so the VM is emulated. `-cpu max,pauth-impdef=on` keeps that fast enough. On an Apple silicon Mac the driver uses Hypervisor.framework. - **Driver fixes for both architectures:** - The virtio NIC runs without its iPXE option ROM. The UEFI firmware has a virtio-net driver, and without Recommends the ROM package is missing. - The driver reports a QEMU that exits before its socket accepts. ## CI - The build, image test and rootfs scan run for both targets; arm64-efi runs on `ubuntu-24.04-arm`. - The jobs are named by target. - Unit tests check both EFI targets' templates, their root partition types, the shared files, and that every target lists its kernel. Dispatch run on this branch: https://github.com/IronFlock/flockos/actions/runs/41952062741, all green. The arm64-efi image test, emulated: | Step | Time | |------|------| | first boot | 103 s | | reboot | 80 s | | update into slot B | 291 s | | fallback | 327 s | Not in this PR: the arm64-efi installer payload. It needs the installer from #156, and comes as a follow-up after #156 merges. Closes #151 except the installer payload.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
tools.lockonly had x86_64 binaries, so a job on an arm64 runner installed tools it could not execute. That also broke the shell gate'sbuild-runs-on: ubuntu-24.04-arm. FlockOS needs that runner for its arm64-efi and Raspberry Pi images.Changes
<name>/arm64line at the same version. Each sha256 is the release asset's published digest; for helm it comes from get.helm.sh's checksum file./arm64line on aarch64 and the plain line on x86_64. The installed binary keeps its usual name, so callers change nothing.scriptsjob.tools-arm64installs every tool onubuntu-24.04-arm, checks that each is an aarch64 binary, and runs it.shell-gate-arm64runs the shell gate's build on that runner.Callers on x86_64 runners get exactly the binaries they got before.