Here is a solution to a problem that existed for months but nobody could reproduce so far. I've tested arm64 native builds and x86. Both work correctly.

Problem

Building Ubuntu 26.04 (Resolute) images natively on an arm64 host targeting arm64 fails at the first chroot operation of the rootfs-cache extraction phase:

thread 'main' panicked at rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called `Result::unwrap()` on an `Err` value: ()

lib/functions/rootfs/distro-specific.sh: line 179: Aborted
LC_ALL="C" LANG="C" LANGUAGE="" SUDO_USER="" chroot "${basedir}" /bin/bash -c \
  "ln -fs armbian-archive-keyring.gpg /usr/share/keyrings/armbian.gpg"

Error 134 at lib/functions/rootfs/distro-specific.sh:289
  create_sources_list_and_deploy_repo_key() -> distro-specific.sh:289
  extract_rootfs_artifact()                 -> rootfs/create-cache.sh:190

Root cause

Ubuntu 26.04 ships uutils as the default coreutils. Those binaries are built on rustix, which reads the process auxiliary vector at startup. When the kernel's primary auxv path fails — observed on Rockchip RK3588 vendor BSP kernels — rustix falls back to reading /proc/self/auxv. Inside a bare chroot that file does not exist, producing the unwrap() panic and aborting the very first chroot command run against a freshly-extracted rootfs.

Why it only affects native arm64→arm64 builds

x86 cross-builds are unaffected because qemu-user supplies the auxv directly, so the /proc fallback is never exercised. This only bites native arm64→arm64 builds, where the framework skips qemu setup entirely:

# lib/functions/rootfs/qemu-static.sh
if dpkg-architecture -e "${ARCH}"; then return 0   # native: no qemu deployed

At the extraction phase (extract_rootfs_artifact → create_sources_list_and_deploy_repo_key "image-early"), mount_chroot() has not run yet, so the target has no procfs — and on native builds there is no qemu to paper over the missing /proc/self/auxv.

Manual reproduction

Against a rootfs extracted outside the build framework, on a native arm64 RK3588 host:

$ sudo chroot /tmp/rtest /bin/ln --version
thread 'main' panicked at rustix/.../auxv.rs:269:22:
called `Result::unwrap()` on an `Err` value: ()
Aborted

$ sudo mount -t proc proc /tmp/rtest/proc
$ sudo chroot /tmp/rtest /bin/ln --version
ln (uutils coreutils) 0.8.0        # works once procfs is present

The fix

Add mount_chroot_proc_for_uutils() (in lib/functions/general/chroot-helpers.sh, next to mount_chroot) and call it from create_sources_list_and_deploy_repo_key() before its chroot commands, tearing it down at the end of the function. The helper:

• Guards on ${target}/proc/self/auxv — mounts procfs only when it is genuinely absent, so it is a no-op when procfs is already present.
• Registers teardown with the cleanup-handler registry (add_cleanup_handler / execute_and_remove_cleanup_handler, mirroring the prepare/done idiom in host/mktemp-utils.sh) rather than a bare umount, so the mount is removed even if a later chroot step aborts partway.
• Uses the framework's run_host_command_logged wrappers and display_alert logging.

Why it's a no-op everywhere else

create_sources_list_and_deploy_repo_key() has three callers:

Only the image-early path runs bare, and only on native builds does the missing auxv actually panic. On the other two callers mount_chroot() already mounted procfs, so the auxv guard short-circuits and the helper does nothing. Cross-builds keep their existing (working) behavior.

Scope

Narrow: the change is confined to the function that contains the failing chroots (create_sources_list_and_deploy_repo_key) plus a reusable helper. Audit confirmed this function is the only chroot invocation in the extraction phase (write_build_resolv_conf merely writes a file), and placing the guard here makes the function self-sufficient regardless of which caller invoked it.

Notes

• Does not touch qemu / binfmt_misc — that is a separate concern.
• No functional change on x86 cross-builds or any post-mount_chroot stage.

Summary by CodeRabbit

• Bug Fixes
  • Improved compatibility with Ubuntu 26.04+ when preparing system files inside a fresh chroot.
  • Ensured required process-information access by automatically mounting and later unmounting proc for specific core utilities when needed.
  • Added safeguards so temporary proc mounts are cleaned up reliably, even if the setup process is interrupted midway.