Where i can get arm binary

Where i can get arm binary without docker?
Docker wont’t run on my arm. And i can`t extract image from container due to container not pull with stopped docker and pull for x86 arch on worked docker on x86.
Please stop rack SNO with docker. Just put binaries for all platform somewhere.

4 Likes

Oh come on. Just compile it yourself. “git clone” the code, look at the Makefile. Or check the thread about docker-less storage I opened a couple weeks or so ago. It’s reasonably easy.

Firstly this suggestion is timebomb because in whitepaper i see storjlabs want to implement binary check, that writeoff custom builds.
Next code in github maybe not contains some variables or other things.
Next building need infrastructure and many more unneeded software.
Next update process with rebuilding all on powerless arm is ugly.

Actually (with help Vladislav Solovei from Russian Telegram storj chat) i work around this problem by pull which container’s digest.
But binaries strongly appreciated…

Hi @Krey
Jocelyn here – I manage the Community team at Storj.

Thanks for asking your arm without docker question here in the forum where answers can be useful to other people.

We love it when the tone of conversations here stays productive and respectful.

Have you tried using the search function to pull up the answers? you can also search on tags and filter for “solved” questions to narrow down the results

i try to search with keyword “binary” and nothing found.
Search for “without docker” is bad idea because i get search for words docker and(or?) without.

Can you elaborate on this? I have an armv71 system and Docker runs fine on it.

Workaround:

  1. Go to a system that has Docker (architecture does not matter).

  2. Check on the Docker Hub for the latest beta tag and copy the image ID for the appropriate architecture. For example, the ID for the latest ARMv6 image is 6b40507028117c48c63ad717169f21d04fa3c6d3594525c4400d46780d2f3090.

  3. Create a temporary container using the image ID to specify that exact image. Note that we don’t run the container, so we don’t need to be on the same architecture:

    docker create --name storagenode-temp storjlabs/storagenode@sha256:6b40507028117c48c63ad717169f21d04fa3c6d3594525c4400d46780d2f3090
    
  4. Copy the binary out of the container:

    docker cp storagenode-temp:/app/storagenode .
    
  5. Remove the temporary container:

    docker rm storagenode-temp
    
  6. Observe that the binary is of the architecture matching the image you selected:

    # file storagenode
    storagenode: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=GhojACuhBSNzNycvnCbM/XWHapOmqTxclfIoVUeVo/mM8JXMPdkJzZAwsuZaz-/QVbVAee2Joqo-ON8sQS2, stripped
    
  7. Copy the binary where you need it.

Obviously this is a bit of a pain and you have to redo it all when an update is released (make sure to get the new image ID!) but it’s at least possible. You could even write a script to make updates easier.

3 Likes

OK. First I apologize for the tone of my initial reply, that was un-called for.

That being said, Storj is open source for a reason. I for one refuse to run closed-source binaries on any computer in my home and would leave the network immediately when somebody tried to enforce only running closed or signed code.

Also, nobody prevents you from forging a code signature (just run the signature check on the official Docker image – but not on the code that’s actually running). Thus I regard the whitepaper’s binary check as a non-issue. Good behavior cannot be enforced with a digital signature.

Also², you can easily cross-compile the code, no need to do that on a poor little ARM machine. There’s also no infrastructure involved, other than installing your distribution’s latest Go compiler package.

2 Likes

Maybe problem was not in arm themself but in default OVH kernel or OS image. Docker wont run with errors about storage driver. No overlay or aufs worked. I try to resolve This about 4 hours and gave up.

Thanks for solution it worked, i pull up node exact this way.

I was going to say something like this, too. The only way to enforce this with any reasonable expectation of success is to require a TPM-signed attestation, and then you exclude all platforms without a TPM or without OS-level support for the TPM. I’d wager that this would probably exclude much of the existing network, making it a non-starter to require a TPM attestation from the node.