@JustSoup321 noticed this in a recent CI run (build-aarch64), the runner was ci-x64-runner3-docker-postmarketos (x86_64 CPU):
>>> device-pine64-pinephonepro: Analyzing dependencies...qemu-aarch64-static: QEMU internal SIGSEGV {code=128, addr=0}Segmentation fault (core dumped)< that repeats a few more times ... >qemu: uncaught target signal 11 (Segmentation fault) - core dumpedSegmentation fault (core dumped)>>> ERROR: device-pine64-pinephonepro: builddeps failed
Important
If you noticed this failure, please comment below with the runner! The runner name is usually visible on the right side of the CI job page, or at the top of the CI job output, like:
Running with gitlab-runner 17.5.2 (c6eae8d7) on 5: ci-x64-runner3-docker-postmarketos hnB2RHmXb, system ID: s_5433359204a5...
Knowing whether or not this happens on specific runners could be helpful for identifying the problem.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
I tried an experiment where I told CI to use aarch64 runners for ARM build testing (so no binfmt/qemu involved), and I see a failure that looks familiar. This was an aarch64 runner building stuff for armv7:
Thanks for posting the reports. Please add new reports when you see more failures, this helps with finding a pattern and shows whether this is still relevant.
I've opened an issue with OSUOSL about it (support ticket ID #33621).
EDIT: I also see mvdan.cc/sh/interp: /usr/lib/go/pkg/tool/linux_arm64/compile: fork/exec /usr/lib/go/pkg/tool/linux_arm64/compile: exec format error happening only sometimes, not sure if that is caused by the same problem:
I suspect this is a bug in the overlayfs kernel driver, possibly upgrading the kernel would fix it. OSUOSL recommended that we upgrade one node from Alma Linux 8 to 9 and see if that fixes it, so we'll do that.
FYI some time ago I added each runner name as a tag for each runner, so you should be able to target jobs on individual runners by using the tag... e.g. to only run jobs on runner4, in .gitlab-ci.yml add something like this for the job:
Not sure if we can upgrade the kernel or if it already is on the latest patch level. If that does not help it either, using BTRFS as storage driver is what we will try next.