ilkermanap
5865198240
Proxmox VE 9.2 made arm64 official — same code base, repositories and release
lifecycle as x86-64 — and the pve-no-subscription repository carries proxmox-ve,
pve-manager, proxmox-default-kernel and pve-qemu-kvm for it. The build was still
hard-wired to amd64 in four places, which is now fixed:
* firmware is chosen from the target architecture (AAVMF for arm64, OVMF for
amd64) and padded to 64 MiB as QEMU's arm64 virt machine requires. Upstream
packer-maas keys this on the host architecture, which only works when host
and target match.
* host_is_arm is derived from uname rather than hard-coded false, so KVM is
used exactly when host and target architectures agree
* the release body builds its MAAS upload command from MAAS_ARCH, PVE_VERSION
and IMAGE_NAME instead of repeating amd64
* install-deps.sh installs qemu-system-arm and AAVMF under WITH_ARM64=1,
off by default since they are useless on an amd64-only builder
verify-image.sh asserted no kernel matching *-amd64, which would have passed
silently on an arm64 image carrying a Debian arm64 kernel. It now rejects any
/boot/vmlinuz-* not ending in -pve, which holds for both architectures. Checking
that with synthetic file lists caught a first attempt that returned "pass" for an
image containing both a PVE and a Debian kernel, so the expression is now a single
pipeline verified against GNU grep on the build host — the macOS grep this was
first tried on disagrees, and only the Linux behaviour matters here.
No arm64 image has been built and none deployed. The README gains an arm64
section saying so plainly, listing the two real obstacles — TCG emulation on an
x86_64 builder, and having no arm64 hardware to deploy to — and the entry stays
under "Not verified".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
12 KiB
12 KiB