Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not run on Raspberry Pi 4 #9

Open
conrad82 opened this issue Feb 4, 2021 · 13 comments
Open

Does not run on Raspberry Pi 4 #9

conrad82 opened this issue Feb 4, 2021 · 13 comments

Comments

@conrad82
Copy link

conrad82 commented Feb 4, 2021

I am unable to run archivy through docker-compose on Raspberry Pi 4.
It runs fine if I install it directly on the RPi using pip3 install archivy

I am running ubuntu server 20.10 (64-bit).
Since it runs outside docker, I suspect it is related to the Dockerfile, but I am not able to see the cause.

I get the following error in the docker logs:
archivy_1 | standard_init_linux.go:211: exec user process caused "exec format error"

Elasticsearch is running fine.
Snippet of my docker-compose.yml file below
(I also run other containers not shown. The container is exposed through a Caddy reverse proxy):

version: '3.4'
services:

  archivy:
  # https://github.com/archivy/archivy-docker/blob/main/docker-compose.yml
    image: uzayg/archivy:v1.0.0
    restart: unless-stopped
    environment:
      - FLASK_DEBUG=0
      - ELASTICSEARCH_ENABLED=1
      - ELASTICSEARCH_URL=http://elasticsearch:9200/
    volumes:
      - ./archivy/data:/archivy/data
      - ./archivy/config:/archivy/.local/share/archivy
  elasticsearch:
    image: elasticsearch:7.9.0
    restart: unless-stopped
    volumes:
      - ./archivy/elasticsearch/data:/usr/share/elasticsearch/data:rw
    environment:
      - "discovery.type=single-node"

Reading a bit in your repository, I see an issues note that it does not work on arm due to pandoc is missing. I am able to install pandoc on ubuntu server on the raspberry pi using apt. Is this issue related to base image being alpine? Not sure if it is related to the error though..

@Uzay-G
Copy link
Member

Uzay-G commented Feb 4, 2021

Someone else has been getting this error, but it's not related to pandoc because we removed that dependency. I'll look into it :)

@conrad82
Copy link
Author

conrad82 commented Feb 4, 2021

Wow quick response! :)
I could find the error message around the web, but a bit unclear to me how it relates to this project

Congrats on v1.0 :)

@Jafner
Copy link
Contributor

Jafner commented Feb 4, 2021

@conrad82 Can you post your full docker logs archivy?
More information to debug with can't hurt.

@conrad82
Copy link
Author

conrad82 commented Feb 5, 2021

@Jafner , the log is not very exciting I'm afraid:
(I assume multiple lines is caused by restart: unless-stopped )

standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
...

Tested with FLASK_DEBUG=1 also, just in case. No difference.

@conrad82
Copy link
Author

conrad82 commented Feb 5, 2021

I tried building it myself (I forked archivy-docker repo to https://github.com/conrad82/archivy-docker )

First it fails at step 3

Step 3/18 : RUN pip3.9 install --prefix=/install archivy==$VERSION
 ---> Running in 6cd98dfb29af
ERROR: Could not find a version that satisfies the requirement archivy==
ERROR: No matching distribution found for archivy==
ERROR: Service 'archivy' failed to build: The command '/bin/sh -c pip3.9 install --prefix=/install archivy==$VERSION' returned a non-zero code: 1

I simplified the install command to pip3 install archivy
It then fails at brotli installation, from the error messages I suspect due to missing gcc
Added steps for installing gcc and g++ - brotli succeeds!

After some more tweaking, I got it to start with the following changes to the code! :
https://github.com/archivy/archivy-docker/compare/main...conrad82:main?diff=unified
The code is a bit hacky, so I wasn't planning a pull request. Also, the modifications are quite small.

Now the logs look like this:

$ sudo docker logs archivy
Setting environment variables.
The following environment variables were set:
		FLASK_DEBUG=1
		ELASTICSEARCH_ENABLED=1
		ELASTICSEARCH_URL=http://elasticsearch:9200/
		ARCHIVY_PORT=5000
Checking if Elasticsearch is up and running
Elasticsearch is running @ http://elasticsearch:9200/.
Starting Archivy
Running archivy...
[2021-02-05 12:06:52,148] INFO in __init__: OUTPUT_FOLDER: /tmp/click-web
 * Serving Flask app "archivy" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: on
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
 * Restarting with stat
Running archivy...
[2021-02-05 12:06:56,087] INFO in __init__: OUTPUT_FOLDER: /tmp/click-web
 * Debugger is active!
 * Debugger PIN: 326-819-398

I don't get the web page up through my reverse proxy though,... I'll have to take a look another time..

@srevinsaju
Copy link
Member

Raspberry Pi has arm architecture. Ans in this case, Rpiv4 has aarch64. amd64 builds of docker containers cannot run on aarch64. Ideally, arm buillds should be pushed to hub.docker.com instead and users should be able to pull the docker containers for the respective architecture like archivy-armhf or archivy-aarch64 depending on the architecture. So, currently, there is no way to use archivy's docker image on an arm arch device like Rpi4 or on Android. The only solution is to build from source.

@srevinsaju
Copy link
Member

And also, I took a look at https://github.com/archivy/archivy-docker/compare/main...conrad82:main?diff=unified. At one end, the base image should be arm32v7/python or arm32v6/python and not python:3.9-alpine for optimal performance.

@callingshotgun
Copy link

Ping - It's been a couple months since this issue was last discussed. Any chance it can get some attention?

@Jafner
Copy link
Contributor

Jafner commented Apr 17, 2021

Ping - It's been a couple months since this issue was last discussed. Any chance it can get some attention?

Thanks for the reminder. I'm gonna do some testing and dev this weekend. I'll keep this thread up to date on my efforts.
It's a simple conversion on paper, but I don't have an arm64 device to test with.

@Jafner
Copy link
Contributor

Jafner commented Apr 17, 2021

@callingshotgun Have you tried building a copy from the dockerfile in the archivy-docker repository?
It's based on the python:3.9-alpine tag, which is a multi-architecture tag. I believe our current workflow builds a single amd64 image from the dockerfile before sending it to dockerhub. If you build the image yourself from the dockerfile it should automatically switch to the arm64 version of python:3.9-alpine during the build process.

Let me know if this works for you. If it does, we can probably add an arm64 build to the workflow.

@callingshotgun
Copy link

Thanks @Jafner ! Alas, did not work.

Attached log. Command I tried was
docker build https://github.com/archivy/archivy-docker.git#main --build-arg VERSION=1.1.4

Was that the right version number to use? It seemed to go south trying to add Brotli to the image.

Collecting brotli
  Downloading Brotli-1.0.9.zip (510 kB)
WARNING: The candidate selected for download or install is a yanked version: 'validators' candidate (version 0.15.0 at https://files.pythonhosted.org/packages/c4/4a/4f9c892f9a9f08ee5f99c32bbd4297499099c2c5f7eff8c617a57d31a7d8/validators-0.15.0.tar.gz#sha256=31e8bb01b48b48940a021b8a9576b840f98fa06b91762ef921d02cb96d38727a (from https://pypi.org/simple/validators/))
Reason for being yanked: Missing python_requires in setup.py

archivy-docker-build-output.txt

@Uzay-G
Copy link
Member

Uzay-G commented Dec 23, 2021

I want to fix this. Could someone with a raspberry pi join the discord server and ping me so we can troubleshoot it? I'm not sure why but it seems gcc has problems installing on an arm device - either way doing multi-architecture images would be good.

@Uzay-G
Copy link
Member

Uzay-G commented Dec 23, 2021

We can probably do something like what's outlined here: https://www.docker.com/blog/multi-arch-images/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants