bitcoind: cannot execute binary file: Exec format error

[BlackHatCoiner]

I was trying to upgrade to 22.0, but it can't run the binaries:

Code:

admin@raspibolt:/tmp/bitcoin-22.0 $ bitcoind
-bash: /usr/local/bin/bitcoind: cannot execute binary file: Exec format error

I've downloaded bitcoin-22.0-aarch64-linux-gnu.tar.gz and according to my RPi 4, I need ARMv7 binaries. Raspibolt tells me to download this as well:

Code:

# download Bitcoin Core binary
$ wget https://bitcoincore.org/bin/bitcoin-core-22.0/bitcoin-22.0-aarch64-linux-gnu.tar.gz

Any idea what's wrong? No help from Google.

[1714183427]

1714183427

[1714183427]

1714183427

[1714183427]

1714183427

[n0nce]

I was trying to upgrade to 22.0, but it can't run the binaries:

Code:

admin@raspibolt:/tmp/bitcoin-22.0 $ bitcoind
-bash: /usr/local/bin/bitcoind: cannot execute binary file: Exec format error

I've downloaded bitcoin-22.0-aarch64-linux-gnu.tar.gz and according to my RPi 4, I need ARMv7 binaries. Raspibolt tells me to download this as well:

Code:

# download Bitcoin Core binary
$ wget https://bitcoincore.org/bin/bitcoin-core-22.0/bitcoin-22.0-aarch64-linux-gnu.tar.gz

Any idea what's wrong? No help from Google.

It is trying to execute the binary at the path /usr/local/bin/bitcoind and not /tmp/bitcoin-22.0/bitcoind. For whatever reason, whatever's at /usr/local/bin/bitcoind is somehow faulty.
You're missing a mere 2 characters...
It should be: admin@raspibolt:/tmp/bitcoind-22.0 $ ./bitcoind

[BlackHatCoiner]

It is trying to execute the binary at the path /usr/local/bin/bitcoind and not /tmp/bitcoin-22.0/bitcoind.

Same thing happens when I execute it with “./” in /tmp/bitcoin-22.0/bin.

Code:

admin@raspibolt:/tmp/bitcoin-22.0/bin $ ./bitcoind
-bash: ./bitcoind: cannot execute binary file: Exec format error

According to others who had the same issue, it's just something wrong with the architecture. The problem is that I've looked it up and I'm using the correct architecture: Arch 64-bit.

For whatever reason, whatever's at /usr/local/bin/bitcoind is somehow faulty.

Well... It's probably the binaries of 0.21.1. I didn't uninstall it. I just stopped it and redid the installation, but with 22.0 this time.

[n0nce]

It is trying to execute the binary at the path /usr/local/bin/bitcoind and not /tmp/bitcoin-22.0/bitcoind.

Same thing happens when I execute it with “./” in /tmp/bitcoin-22.0/bin.

Code:

admin@raspibolt:/tmp/bitcoin-22.0/bin $ ./bitcoind
-bash: ./bitcoind: cannot execute binary file: Exec format error

According to others who had the same issue, it's just something wrong with the architecture. The problem is that I've looked it up and I'm using the correct architecture: Arch 64-bit.

Sounds right: 3 things must match - hardware architecture, OS and the binary.
It is possible that you're running 32-bit Linux on a 64-bit CPU. Then, 64-bit binaries won't run on it even if you have the required hardware. While it's not possible running x86 OS on ARM CPU, it's possible you simply got x86 binaries instead of ARM, but it doesn't seem the case. Worth verifying though.
Simplest thing in my opinion, is avoiding binaries and compiling yourself; takes a bit more time and a few more steps, but gives better security (less trust) & it will run.

For whatever reason, whatever's at /usr/local/bin/bitcoind is somehow faulty.

Well... It's probably the binaries of 0.21.1. I didn't uninstall it. I just stopped it and redid the installation, but with 22.0 this time.

That's not an issue; if it compiles and installs correctly, it will just overwrite the old one.

[PawGo]

What is your kernel?
What is the output of

Code:

uname -a

?

As they said: (https://ispltd.org/desktops:arch_on_raspberry_pi4)
Raspberry Pi 4 uses an ARMv7 processor according to its /proc/cpuinfo file, although Wikipedia says that it is an ARM Cortex A72, which is an ARMv8 model. The v7 architecture is 32-bit architecture while the v8 is 64-bit. I don't know why they mix these two architectures, but presume that the 32-bit code can run on a 64-bit chip and point out my observations here for your awareness.

If you have indeed 32bit OS, would it be possible to change it?
https://downloads.raspberrypi.org/raspios_arm64/images/

[BlackHatCoiner]

Worth verifying though.

How? The Bitcoin Core download page shows both 64 and 32 bit binaries and I'm sure I choose the former. (I also tried with the latter, but same error)

Simplest thing in my opinion, is avoiding binaries and compiling yourself; takes a bit more time and a few more steps, but gives better security (less trust) & it will run.

How does it give better security and less trust if I'm verifying the signature of the installer? Also, why will it then run? Is it going to build it according to my OS, architecture etc.?

What is your kernel?
What is the output of

Code:

uname -a

?

Code:

admin@raspibolt:/usr/local/bin $ uname -a
Linux raspibolt 5.10.52-v7l+ #1441 SMP Tue Aug 3 18:11:56 BST 2021 armv7l GNU/Linux

If you have indeed 32bit OS, would it be possible to change it?
https://downloads.raspberrypi.org/raspios_arm64/images/

This sounds like a big trouble.

[n0nce]

Worth verifying though.

How? The Bitcoin Core download page shows both 64 and 32 bit binaries and I'm sure I choose the former. (I also tried with the latter, but same error)

If you did get ARM Linux (64 Bit) it should be good. You need the 32 bit binary if your OS is 32 bit.

Simplest thing in my opinion, is avoiding binaries and compiling yourself; takes a bit more time and a few more steps, but gives better security (less trust) & it will run.

How does it give better security and less trust if I'm verifying the signature of the installer? Also, why will it then run? Is it going to build it according to my OS, architecture etc.?

Well, the signature proves nobody messed with the download in transit, but someone could have uploaded a malicious binary to the official download page itself. If you also verify PGP, you can know that a trusted developer built and uploaded the binary, but a developer can also become malicious. So the safest route to make sure you're actually running the code that you see on Bitcoin's GitHub, is to download and build it yourself.

It will also indeed detect the right OS and architecture & build a binary that runs on it.

What is your kernel?
What is the output of

Code:

uname -a

?

Code:

admin@raspibolt:/usr/local/bin $ uname -a
Linux raspibolt 5.10.52-v7l+ #1441 SMP Tue Aug 3 18:11:56 BST 2021 armv7l GNU/Linux

Seems like this is 32-bit Linux. So maybe just try installing the 32-bit version of the software. Best would be to reinstall the 'right' OS (64-bit Raspbian) but it's a lot of hassle and not really worth it, probably.

[PawGo]

Exactly. But what happens when you try to launch a precompiled ‘arm’ version from bitcoin download site?

[vv181]

What is your kernel?
What is the output of

Code:

uname -a

?

Code:

admin@raspibolt:/usr/local/bin $ uname -a
Linux raspibolt 5.10.52-v7l+ #1441 SMP Tue Aug 3 18:11:56 BST 2021 armv7l GNU/Linux

Seems like this is 32-bit Linux. So maybe just try installing the 32-bit version of the software. Best would be to reinstall the 'right' OS (64-bit Raspbian) but it's a lot of hassle and not really worth it, probably.

The earlier version of Raspibolt was indeed using 32bit OS. Though, if @BlackHatCoiner want to upgrade the OS, it's probably best to follow the tutorial from the site: Can I update my RaspiBolt 2 to the new version?. Just make sure to backup all the data/application that are not parts of the tutorial.

[BlackHatCoiner]

Well, the signature proves nobody messed with the download in transit, but someone could have uploaded a malicious binary to the official download page itself.

That's why I'm verifying the signatures. Because, the developers' public keys are outside the download page. An attacker needs to compromise both keys.ubuntu.com and bitcoincore.org.

If you also verify PGP, you can know that a trusted developer built and uploaded the binary, but a developer can also become malicious.

But, there's this trust whether I build the source code myself or not, unless I check every single line. Even if I do, I have to trust my coding skills. If we reach to the point where we don't trust the developers, then it's a dead end.

Seems like this is 32-bit Linux.

Is it the ArmV7 that made you conclude so? Damn, I haven't used to use Linux yet.

So maybe just try installing the 32-bit version of the software.

As I said, I did. I downloaded bitcoin-22.0-arm-linux-gnueabihf.tar.gz (which is 32-bit) and it prompt the same error.

The earlier version of Raspibolt was indeed using 32bit OS.

How early? I set it up in August.

Exactly. But what happens when you try to launch a precompiled ‘arm’ version from bitcoin download site?

Isn't bitcoin-22.0-aarch64-linux-gnu.tar.gz considered pre-compiled?

[vv181]

The earlier version of Raspibolt was indeed using 32bit OS.

How early? I set it up in August.

As on their Github page[1], they migrated to Raspibolt V3 on 8 December 2021. The former of that date is using Raspibolt V2, which was using 32bit.

[1] https://github.com/raspibolt/raspibolt/releases


The V2 tutorial of Bitcoin installation was placed on "/usr/local/bin". If the downloaded 32bit file isn't executable, I would suggest comparing both of the binary using "file ./bitcoind" command to make sure the file is in the correct architecture.

Code:

file /usr/local/bin/bitcoind
file /tmp/xx/bitcoind #bitcoin 22.0 filepath

Or maybe you can try the V2 upgrade guide: https://v2.raspibolt.org/raspibolt_30_bitcoin.html#installation

[BlackHatCoiner]

As on their Github page[1], they migrated to Raspibolt V3 on 8 December 2021. The former of that date is using Raspibolt V2, which was using 32bit.

Yep, that's what I had. I reinstalled it and the problem was magically resolved. But, I now have another one:

Code:

bitcoin@raspibolt:~ $ bitcoind
2022-02-20T21:06:09Z Bitcoin Core version v22.0.0 (release build)
2022-02-20T21:06:09Z InitParameterInteraction: parameter interaction: -proxy set -> setting -upnp=0
2022-02-20T21:06:09Z InitParameterInteraction: parameter interaction: -proxy set -> setting -natpmp=0
2022-02-20T21:06:09Z Assuming ancestors of block 00000000000000000008a89e854d57e5667df88f1cdef6fde2fbca1de5b639ad have valid signatures.
2022-02-20T21:06:09Z Setting nMinimumChainWork=00000000000000000000000000000000000000001fa4663bbbe19f82de910280
2022-02-20T21:06:09Z Using the 'standard' SHA256 implementation
2022-02-20T21:06:09Z Default data directory /home/bitcoin/.bitcoin
2022-02-20T21:06:09Z Using data directory /home/bitcoin/.bitcoin
2022-02-20T21:06:09Z Config file: /home/bitcoin/.bitcoin/bitcoin.conf
2022-02-20T21:06:09Z Config file arg: blocksonly="0"
2022-02-20T21:06:09Z Config file arg: dbcache="2000"
2022-02-20T21:06:09Z Config file arg: discover="1"
2022-02-20T21:06:09Z Config file arg: listen="1"
2022-02-20T21:06:09Z Config file arg: listenonion="1"
2022-02-20T21:06:09Z Config file arg: maxconnections="40"
2022-02-20T21:06:09Z Config file arg: maxuploadtarget="5000"
2022-02-20T21:06:09Z Config file arg: onlynet="onion"
2022-02-20T21:06:09Z Config file arg: proxy="127.0.0.1:9050"
2022-02-20T21:06:09Z Config file arg: rpcallowip="127.0.0.1"
2022-02-20T21:06:09Z Config file arg: rpcauth=****
2022-02-20T21:06:09Z Config file arg: rpcbind=****
2022-02-20T21:06:09Z Config file arg: server="1"
2022-02-20T21:06:09Z Config file arg: txindex="1"
2022-02-20T21:06:09Z Config file arg: zmqpubrawblock="tcp://127.0.0.1:28332"
2022-02-20T21:06:09Z Config file arg: zmqpubrawtx="tcp://127.0.0.1:28333"
2022-02-20T21:06:09Z Using at most 40 automatic connections (1024 file descriptors available)
2022-02-20T21:06:09Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2022-02-20T21:06:09Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2022-02-20T21:06:09Z Script verification uses 3 additional threads
2022-02-20T21:06:09Z scheduler thread start
2022-02-20T21:06:09Z Binding RPC on address 127.0.0.1 port 8332 failed.
2022-02-20T21:06:09Z Unable to bind any endpoint for RPC server
2022-02-20T21:06:09Z Error: Unable to start HTTP server. See debug log for details.
Error: Unable to start HTTP server. See debug log for details.
2022-02-20T21:06:09Z Shutdown: In progress...
2022-02-20T21:06:09Z scheduler thread exit
2022-02-20T21:06:09Z Shutdown: done

It seems like it fails binding to RPC. I tried to restart Tor, nothing, I rebooted RPi, nothing, I killed Tor & Bitcoin processes and restarted, nope. That's my configuration file:

Code:

# RaspiBolt: bitcoind configuration
# /mnt/ext/bitcoin/bitcoin.conf

# Bitcoin daemon
server=1
txindex=1

# Network
listen=1
listenonion=1
proxy=127.0.0.1:9050
onlynet=onion
discover=1
#bind=0.0.0.0


# Connections
#rpcuser=XXXXXXX
#rpcpassword=XXXXXX
rpcauth=XXXXXX:XXXXXXXX
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
rpcbind=127.0.0.1
rpcallowip=127.0.0.1


# Raspberry Pi optimizations
maxconnections=40
maxuploadtarget=5000

# Initial block download optimizations
dbcache=2000
blocksonly=0

[vv181]

Code:

2022-02-20T21:06:09Z Binding RPC on address 127.0.0.1 port 8332 failed.
2022-02-20T21:06:09Z Unable to bind any endpoint for RPC server
2022-02-20T21:06:09Z Error: Unable to start HTTP server. See debug log for details.
Error: Unable to start HTTP server. See debug log for details.

It seems like it fails binding to RPC. I tried to restart Tor, nothing, I rebooted RPi, nothing, I killed Tor & Bitcoin processes and restarted, nope.

I don't know for sure but maybe the port is already being used. Try to verify and see which application is using it with the below command:

Code:

sudo netstat -lp | grep 8332

If the output shows the port, I think the bitcoin daemon is already running because of the default Raspibolt service configuration.

[n0nce]

Well, the signature proves nobody messed with the download in transit, but someone could have uploaded a malicious binary to the official download page itself.

That's why I'm verifying the signatures. Because, the developers' public keys are outside the download page. An attacker needs to compromise both keys.ubuntu.com and bitcoincore.org.

Correct!

If you also verify PGP, you can know that a trusted developer built and uploaded the binary, but a developer can also become malicious.

But, there's this trust whether I build the source code myself or not, unless I check every single line. Even if I do, I have to trust my coding skills. If we reach to the point where we don't trust the developers, then it's a dead end.

No, if you're building yourself you have less trust involved. Even if you don't read the source code.
Building: Trust the source code is fine.
Downloading: Trust the source code is fine + Trust the person who built & uploaded it didn't mess with the code before building.
That's where the concept of verifiable / reproducible builds come in. It allows to prove a certain binary was built from a certain codebase (without modifications to the codebase); I don't think that verifying Core builds is commonly done (or possible?) though.

Seems like this is 32-bit Linux.

Is it the ArmV7 that made you conclude so? Damn, I haven't used to use Linux yet.

Yes, ARMv7 is 32-bit
https://en.wikipedia.org/wiki/ARM_architecture#32-bit_architecture

So maybe just try installing the 32-bit version of the software.

As I said, I did. I downloaded bitcoin-22.0-arm-linux-gnueabihf.tar.gz (which is 32-bit) and it prompt the same error.

Okay, that's odd.
Did you follow the normal Bitcoin Core guide? https://bitcoin.org/en/full-node#linux-instructions

Code:

tar xzf bitcoin-22.0-arm-linux-gnueabihf.tar.gz
bitcoin-22.0/bin/bitcoind

I'm also not 100% sure if it runs directly out of the download directory or for whatever reason needs to be installed with the sudo install... (don't think that's the issue based on that error message though).

Regarding port bindings, probably your existing Bitcoin Core is still running. Even if you shut it down using bitcoin-cli stop, it will come back up. You will need to locate the service name (e.g. bitcoin-service, then stop it with sudo service bitcoin-service stop). After stopping the service, install the new version.

[BlackHatCoiner]

I don't know for sure but maybe the port is already being used. Try to verify and see which application is using it with the below command:

It's used:

Code:

bitcoin@raspibolt:~ $ sudo netstat -lp | grep 8332
tcp        0      0 localhost:28332         0.0.0.0:*               LISTEN      27931/bitcoind
tcp        0      0 localhost:8332          0.0.0.0:*               LISTEN      27931/bitcoind
tcp6       0      0 localhost:8332          [::]:*                  LISTEN      27931/bitcoind

I, then, kill those processes:

Code:

bitcoin@raspibolt:~ $ kill -9 27931
bitcoin@raspibolt:~ $

Re-called bitcoind, same error.


And few minutes afterwards, it's working. I don't know if it's a miracle, but it's syncing right now. I just redid the exact thing above. I honestly can't understand Linux often.

[n0nce]

I'm also not 100% sure if it runs directly out of the download directory or for whatever reason needs to be installed with the sudo install... (don't think that's the issue based on that error message though).

You can run Bitcoin Core direlty after you extract the archive. Usually i do that since i don't want to bother with update or uninstall. Using sudo install is only needed if you want Bitcoin Core integrated on your system.

That's good to know. I thought install was just copying the binary to /usr/bin or something else on the OSes path, but wasn't 100% sure.

Regarding port bindings, probably your existing Bitcoin Core is still running. Even if you shut it down using bitcoin-cli stop, it will come back up. You will need to locate the service name (e.g. bitcoin-service, then stop it with sudo service bitcoin-service stop). After stopping the service, install the new version.

Unless OP use different directory between old and new version, Bitcoin Core should quit earlier due with error message "Cannot obtain a lock on data directory".

You mean Bitcoin data directory, right? By default, it should always pick ~/.bitcoin indeed.

And few minutes afterwards, it's working. I don't know if it's a miracle, but it's syncing right now. I just redid the exact thing above. I honestly can't understand Linux often.

It was probably still exiting. -9 gives the normal shutdown signal (no 'hard kill'); I believe bitcoind captures it and exits cleanly (but it does take a bit to flush everything to disk).

Happy to hear you got it running!

[NotATether]

As others have already mentioned, you tried to run ARM64 binaries on an ARM32 OS (aarch64 software is for ARM64 hardware  )

It was probably still exiting. -9 gives the normal shutdown signal (no 'hard kill'); I believe bitcoind captures it and exits cleanly (but it does take a bit to flush everything to disk).

-9 actually sends SIGKILL which terminates the process immediately. Perhaps the OS was still cleaning up the port resources and he restarted Core too quickly. Happens to me sometimes with other software.

[n0nce]

-9 actually sends SIGKILL which terminates the process immediately. Perhaps the OS was still cleaning up the port resources and he restarted Core too quickly. Happens to me sometimes with other software.

Oh wow, that's good to know, I totally misremembered, thanks! Always been using -9 under the impression it's basically CTRL+C if running something directly on cli (not as daemon)..

CTRL+C indeed corresponds to SIGINT (-2) instead.