🐛Illegal instruction on armv6l

[giondo]

Describe the bug
Trying to run cloudflared on a raspberry pi zero w
tried also the version on the repositories
deb http://archive.raspberrypi.org/debian/ bullseye main

To Reproduce
Steps to reproduce the behavior:

1. Configure '...'
   Download and install cloudflared-linux-armhf.deb
   cloudflared/now 2023.10.0 armhf [installed,local]
   Cloudflare Tunnel daemon

2. Run '....'
   cloudflared
   Illegal instruction

3. See error
   Illegal instruction

If it's an issue with Cloudflare Tunnel:
6. Tunnel ID :
7. cloudflared config:

Expected behavior
Able to run the command with a normal output

Environment and versions

• OS: Linux hostname 6.1.21+ #1642 Mon Apr 3 17:19:14 BST 2023 armv6l GNU/Linux

• Architecture: [e.g. AMD, ARM] armv6l

• Version: [e.g. 2022.02.0]
  Architecture: armv6l
  Byte Order: Little Endian
  CPU(s): 1
  On-line CPU(s) list: 0
  Thread(s) per core: 1
  Core(s) per socket: 1
  Socket(s): 1
  Vendor ID: ARM
  Model: 7
  Model name: ARM1176
  Stepping: r0p7
  CPU max MHz: 1000.0000
  CPU min MHz: 700.0000
  BogoMIPS: 697.95
  Flags: half thumb fastmult vfp edsp java tls

Logs and errors
If applicable, add logs or errors to help explain your problem.

Additional context

[theStanister]

I'm having the same problem too, except mine is hosted in an Asus router on Armv6 running the cloudflared-linux-arm binary. I've reverted back to 2023.8.2 manually for now but due to the non-persistent state of the router firmware, we have to run with parameter "service install' every time, and it looks like the service install parameters may trigger cloudflared to download the latest release to copy to init.d ? So this would be an issue for us if the latest version that gets automatically uploaded, results in illegal instructions, as that is now affecting production without a workaround.

I'm wondering if this is related to how the -arm and armhf binaries in the releases page are compiled rather than any code changes? there might've been a compile target change?

[shpokas]

Affects me too, same hardware and error message.
Reverting back to an older release helps as a workaround.

[theStanister]

My workaround didnt work. since i have a daily reboot on the router, that workaround lasted only a day before the reboot ran the script again, which, due to the non-persistent nature of the asus firmware, meant the script had to run cloudflared service install again, and that's what appears to be triggering its own OTA upgrade to the latest version. For now I've just given up and had to put the cloudflared tunnel client on another box, which is not ideal because it moves the traffic routing further away from the router (more unnecessary traffic on the LAN). Hopefully this gets fixed soon :(

[Jeremy Loy]

This just started affecting my PiHole that is configured to use DNS over HTTPS via cloudflared.

I have it set to update cloudflared weekly via cron and my guess is that’s why I just started getting hit with this today. The GitHub release was 3 days ago

[João Oliveirinha]

Hi,

I believe the change of build env internally, caused the an env variable to not be passed, so the GOARCH that was used for the ARM binary was v7, when it should be v6.

This also, explains why armhf and arm binaries have the same sha256 checksum, since the only thing that changes is that flag.

@giondo your case seems to be different. This that I just explained happened only for >=2024.1.1
it seems that you are using the armhf binary but isn't your platform armv6? If so, you should use the arm binary, but as stated, that seems to be broken.

We are going to take a look into this tomorrow in more detail.

[João Oliveirinha]

This seems to have gotten fixed in the last release.

[giondo]

dpkg: error processing archive cloudflared-linux-arm.deb (--install):
package architecture (arm) does not match system (armhf)
Errors were encountered while processing:
cloudflared-linux-arm.deb

[theStanister]

I believe the change of build env internally, caused the an env variable to not be passed, so the GOARCH that was used for the ARM binary was v7, when it should be v6.

This also, explains why armhf and arm binaries have the same sha256 checksum, since the only thing that changes is that flag.

Hi @joliveirinha this just happened again today. whatever release that was pushed out a few hours ago propogated to my arm based router that runs the CF binary and it abruptly stopped working. Is there a permanent solution to prevent this?

EDIT: I jumped the gun. i re-downloaded the linux-arm release for v2024.4.0 from the releases page manually and that worked. So I'm not sure which version my router decided to update itself to that didn't. Hmm.

[Jeremy Loy]

@theStanister the releases page works, the packages in the registry don’t. I’ve given up trying to install this library using the package manager and just set it up to curl GitHub.

something about the way the package manager selects binaries based on architecture and what this repo is publishing changed over the past 6 months and fails for certain platforms

[theStanister]

@JeremyLoy yeh it's something to do with packaging. I thought i'd point it out since there are likely users out there using cloudflared in production loads (probably not on a $20 ARM tho but nonetheless it's still a possible production impact). It can be a bit overwhelming if it suddenly happens when you least expect it to, and have no idea how to resolve it quickly.