[BUG] 5.x binaries are not compatible with ARM

[theotherp]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

The new compiled binaries of 5.x don't work with ARM. Please use the generic release for the ARM images. Everything else should be able to stay the same (or as before, whatever).

Expected Behavior

Use the java jar in the generic release.

Steps To Reproduce

.

Environment

.

CPU architecture

arm64

Docker creation

.

Container logs

.

[thespad]

How demanding is the compilation process? Could we do it as part of the container build on arm? If possible we want to avoid having substantially different builds between architectures because it makes it harder to maintain.

[theotherp]

Hold on, I may be able to do this using qemu.

Apart from that all the code is in https://github.com/theotherp/nzbhydra2/tree/master/misc/buildLinuxCore. On a default github hosted runner the build takes about 20 minutes.

[thespad]

We build arm natively - qemu adds a lot of overhead (and breaks with some stuff). Oracle Cloud offers free arm VMs, which might be of use to you for building.

[theotherp]

Uh, nice, thanks for the tip. I'll check it out.

[theotherp]

That seems to have worked. I'll hopefully have an arm64 release later today.

[thespad]

That's great. Do you think 32-bit arm is practical for you to build as well?

For reference this covers our armhf support policy - it's increasingly difficult to support, so where it's going to be loads of work we're sunsetting the armhf builds (though we don't delete any of the old images). Sonarr is probably the highest profile image we've had to do so far.

[theotherp]

Didn't even know 32-bit arm was a thing. Never should've started with the native stuff. I'll start with arm64 and see where it goes.

[thespad]

95% of arm hardware from the last 5 years is 64-bit, but Raspbian was still shipping a 32-bit OS with all new Pis until about a year ago, so lots of people are running 32-bit arm even though their hardware is 64-bit. There are still a few people running actual 32-bit hardware like Pi 2s but there's only so much you can do to support 8 year old kit.

We've been pushing people to migrate off because honestly we'd like to drop it entirely, but we don't want to do it wholesale until the numbers are small enough that it's not going to upset a ton of people. So in the meantime we're just dropping it for images where it's necessary.

[theotherp]

As there's always the generic release as a fallback I'll stick to arm64 then.

[theotherp]

It doesn't look like I'll be able to provide a compiler wrapper for arm64 so you'll have to install python and run the wrapper file instead of running the binary.

[thespad]

That's not a problem, is there any issue with using the wrapper for amd64 as well?

[theotherp]

The python wrapper file will work fine, it's just that I can't compile it for arm64.

[theotherp]

It's up. The name of the release zips has changed: https://github.com/theotherp/nzbhydra2/releases

[thespad]

amd64 & arm builds look good https://ci-tests.linuxserver.io/lspipepr/nzbhydra2/dev-v5.1.0-pkg-948d5790-pr-39/index.html

arm32 using the generic release fails because the CI tests are using qemu, but runs OK natively.

Going to PR the dev branch and get some people to test, then we'll do master if everything seems fine.

[theotherp]

Awesome.

[thespad]

We plan to sunset the 32-bit arm image in a few months time, which will then allow us to drop the JRE once we're happy the majority of users have upgraded to 5.x

[saschabrockel]

Same problem here with an ODROID-N2 with arm64 architecture.

ERROR - Unable to start process; make sure "core" exists and is executable. Error message: [Errno 8] Exec format error: './core'

[thespad]

This should be fixed with v5.1.0-ls87 / dev-v5.1.0-ls101