How to make gitea run again on RPi 3B given the arm7 build issues?

[markusdd]

• Gitea version (or commit ref):1.8.2
• Git version: 1.8.2 release arm 6 and 7
• Operating system: Raspbian with docker
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:
  pi@pi:~/docker/gitea-rpi $ docker-compose up
  Starting gitea

ERROR: for gitea Cannot start service gitea: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: "/usr/bin/entrypoint": stat /usr/bin/entrypoint: no such file or directory": unknown
ERROR: Encountered errors while bringing up the project.

Description

Cannot get latest gitea to run on arm7 raspi 3B.
I maintain this docker image repo for the RPi platform:
https://hub.docker.com/r/markusdd/gitea-rpi
https://github.com/markusdd/gitea-rpi

I already tried changing the download link to arm 6 but that crashes for me with the log above. (The no such file or directory is a spurios error, the binary doesn't properly execute)

Any suggestions to get new gitea back on my RPi? This is a pretty bad issue as I cannot properly access my own private Repos currently...

[zeripath]

The arm6 build should work on RPi3, so I think there is likely to be a problem with your docker-compose.

[markusdd]

I doubt that, as it worked perfectly fine until 1.7.1:

gitea:
container_name: gitea
image: markusdd/gitea-rpi:latest
ports:
- 3000:3000/tcp
- 2222:22/tcp
restart: always
environment:
- USER_UID=1000
- USER_GID=1000
volumes:
- /giteadata:/data

[garyng]

Try this, which works on my rpi 3b+.

[markusdd]

I would like to understand why my image does not work, not being told to use xyz other images. They do not fit my existing database.

[garyng]

Perhaps do a cross-check between your Dockerfile and the repo where you forked from?

... and whoa that attitude though ...

[markusdd]

As there aren't any comments contributing to actually solving the issue I'm closing this.

[garyng]

Because the issue is in your docker-compose.yml file, not gitea.

[markusdd]

No, because someone once again changed paths which external sources like image builders rely on.
Stuff like that should be communicated. Just like with the ARMv7 build, stuff gets silently removed and you have to dig through hundreds of issues to find it.

The Dockerfile was perfectly fine for months and across several revisions.

[zeripath]

Dude, we do this for free, be kinder. I'm sorry you have suffered a problem here and that we were unable to find your solution.

Regarding the issue with the arm7 static build was documented in several issues and we added it to the website. We've still been unable to fix it and really would appreciate some help with it.

What was the cause of your problem in the end ?

If only so we can update the documentation to make it clearer.

[markusdd]

In the end there were 3 problems:

a) armv7 release paths disappeared. The correct way would've been (as ARMv6 is backward comptaible) to still release the links to v7 and put Armv6 builds behind it. This broke basically all automated Gitea docker builds, not only mine.
b) to path to the Dockerfiles I download in my Dockerfile somehow now need a /root at the end which was not necessary before. Also caused automated build failing like a) and caused the entrypoint message in this ticket ultimately.
c) Gitea went into crashloop without any meaningful stdout/stderr output, I found out that the sqlite database file was locked due to some weird circumstances. This was not fixable in any way in place, I had to relocate the whole folder structure, launch an intermediate container on it to somehow restore the .db file and then move back to the old location. There was no process sitting on the .db file casuing the lock (checked with fuser, also the system got rebootet several times, so it must have been an internal db issue)

Sorry for the rant, but that whole issue cost me almost 4 weeks and countless hours to figure out and fix, and the upper comments in the category of 'works for me' or 'should work' were not exactly helpful.

I really appreciate the work you do here, but in this case a bit clearer communication would've gone a long way.