Error loading configuration: fork/exec /build/packer-plugin-arm-image: exec format error

[mikemorris]

I'm trying to get this plugin to run on macOS, and I'm hitting the following error on both the Vagrant and Docker build options documented in the README.

    default:  Error loading configuration:
    default:
    default: fork/exec /root/.packer.d/plugins/packer-plugin-arm-image: exec format error

docker run \
        --rm \
        --privileged \
        -v /dev:/dev \
        -v {$PWD}:/build:ro \
        -v {$PWD}/packer_cache:/build/packer_cache \
        -v {$PWD}/output-arm-image:/build/output-arm-image \
        -e PACKER_CACHE_DIR=/build/packer_cache \
        packer-builder-arm build samples/raspbian_golang.json
running /bin/packer
 Error loading configuration:

fork/exec /build/packer-plugin-arm-image: exec format error

The standalone build no longer works due to the switch from kpartx to losetup in #115. Is this perhaps an issue with a newer version of Packer config syntax, or a need to upgrade these plugins to use the new plugin SDK for Packer v1.7 and later?

[yuval-k]

do you have the new M1 mac? that might explain the difference in the exec format

[yuval-k]

if your mac is indeed M1 the solution might be to publish multi-arch docker images

[mikemorris]

Nope, I'm on an Intel Mac running macOS Monterey 12.1 with Packer 1.7.8

[mikemorris]

This appears to actually just be an issue with where the binary built with go build is placed (not sure if it's a change in a newer version of Go and/or specific to macOS).

packer-plugin-arm-image/Dockerfile

Line 38 in 52faad5

COPY --from=builder /build/packer-plugin-arm-image /bin/packer-plugin-arm-image

assumes the binary will be placed into ./build but on my machine it's instead placed into the repo root, not a subfolder. Moving the binary into the expected directory before building the Docker image avoids this issue.

mkdir build
mv packer-plugin-arm-image ./build
docker build -t packer-builder-arm .

[nfx]

@mikemorris for fun i'm trying to enable native macOS support in #155