SOLUTION:
The issue was - the ‘New UI’ docker image was automatically building for AMD64, but the Linux server is an ARM64/v8.
I had to add QEMU and multi-platform build commands to the docker-image.yml file (in Github Actions).
This creates an additional docker image for ARM64 machines, which loads and runs successfully.
This was discovered by manually building a docker container, and receiving the following message:
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
So if you get that message, you must build your docker image for the platform you are on (or multiple platforms).
** == ** == ** == ** == ** == ** == **
ORIGINAL ERROR:
THE SETUP and ERROR
- I made a fresh ansible install, on a fresh ubuntu 20.04 server - the Lemmy instance runs perfectly.
- I made a fresh fork of the 16.7 Lemmy-UI.
- I built a docker-image of that forked UI, and loaded it via docker-compose (here is my docker-image.yml build file ).
Now I am getting a “502 Bad Gateway - nginx” error (the site does not load).
NGINX error log shows:
connect() failed (111: Connection refused) while connecting to upstream, client: 75.222.232.212, server: ggg.com, request: "GET / HTTP/2.0", upstream: "http://0.0.0.0:15153/", host: "ggg.com"
-
Nginx config has not been modified (but here is the config anyway - ggg.conf)
-
Docker log is clean.
**
DIAGNOSIS
When I list docker containers, there is no PORT mapped to the ‘New-UI’ image container.
(However, when running the ‘default lemmy-UI’ image container, the PORT is successfully mapped to 127.0.0.1:15153->1234/tcp)
It seems I must create a new Container, using the ‘New-UI’ image, and map the PORT to 127.0.0.1:15153->1234/tcp (unless an Environment Variable can do it).
^ Now I must figure out that exact docker command. (because docker run -d -p 127.0.0.1:15153:1234 [ImageID] does not successfully create the container.)
**
Here are the Env Vars I’ve added (in various combinations/values):
lemmy-ui:
environment:
- LEMMY_UI_HTTPS=true
- LEMMY_UI_LEMMY_INTERNAL_HOST=lemmy:8536
- LEMMY_UI_LEMMY_EXTERNAL_HOST=ggg.com
- LEMMY_UI_DISABLE_CSP=true
# - LEMMY_UI_LEMMY_WS_HOST=lemmy:8536
# - LEMMY_UI_HOST=0.0.0.0:1234
here is the full docker-compose.yml (only changed Env Vars)
Those dockers already build for arm64, so i don’t know why you have to use qemu.
Thank you for the reply.
If I can eliminate QEMU, I’d love to (it’s slow).
Have you shared your workflow.yml anywhere? (for the lemmy-ui DockerHub image build)
**
This is my current workflow.yml (for Github Actions).
The reason I added QEMU was:
1 - Github Actions was only building the ‘forked-UI’ docker-image for AMD64.
2 - I then added buildx and specified a platform in the workflow:
- name: Buildx uses: docker/setup-buildx-action@v1 - name: Build and push uses: docker/build-push-action@v2 with: context: . platforms: linux/arm64/v8Which failed with:
Error: buildx failed to solve: process "/dev/.buildkit_qemu_emulator /bin/sh -c yarn install --pure-lockfile" did not complete successfully: exit code: 13 - I then added the QEMU step, and the build succeeded.
**
*Lemmy-Translations
I also had to add an “Update lemmy-translations” step:
- name: Update submodules run: git submodule update --init --recursiveotherwise the build would fail with:
/usr/src/app/generate_translations.js:7 files.forEach(filename => { ^ TypeError: Cannot read properties of undefined (reading 'forEach') at /usr/src/app/generate_translations.js:7:9 at FSReqCallback.oncomplete (node:fs:201:23)After adding that “Update Submodules” step, the build succeeds.
Is there a better way to do it?
**
I am 100% open to any suggestions/critiques (and if your workflow.yml is public, I will study it and learn).
We use drone, there is a .drone.yml file in the root of both lemmy and lemmy-ui. But I don’t understand why you aren’t using the existing images, which are already built for arm.
I forked the UI at 15.4, to build some new UI features.
Next I will manually add those features to this clean fork of Lemmy-UI 16.7 (so all code is up-to-date).
–
If I may ask, do you recognize what this issue might be?
These pages work:
- Home page loads perfectly (when there are 0 posts)
- Create a community works
- visiting a community works (when there are 0 posts)
- New user registration succeeds
–
However, I get a loading spinner and
Uncaught TypeError: Cannot read properties of undefined (reading “____” )on the following pages [in console]:- Create Post (reading “at”)
- User Profile (reading “split”)
- Settings (reading “map”)
And if I do create a post [by using ‘default UI’, and then switching back to ‘forked UI’], then Post-List pages also give that error:
- Community, Home (reading “split").
–
So my question is:
Do you see a likely cause from that pattern?
(Perhaps a backend/database connection - an undefined string).
If you have an idea, I would love to know.
–
ENVIRONMENT:
-
Docker + NGINX logs seem to be clean.
-
I have not modified the ‘UI fork’ code.
-
I have not modified anything on the VPS - only added these Environment Variables in docker-compose.yml (in various combinations):
environment: - LEMMY_UI_LEMMY_INTERNAL_HOST=lemmy:8536 - LEMMY_UI_LEMMY_EXTERNAL_HOST=ggg.com - LEMMY_UI_HTTPS=true - LEMMY_UI_DISABLE_CSP=true - LEMMY_UI_HOST=0.0.0.0:1234- The install was done by ansible.
–
Thank you for your time and work. Lemmy is awesome.
[I am learning about drone now.]
I can’t help you debug forks, you’re on your own there. Its almost certainly because your forked UI is using a wrong version of lemmy-js-client that works with the lemmy backend, so its missing or has incorrect fields in the request JSON.
1 - I’ve completed your suggestions.
You are correct - I had forked the ‘Main’ branch, which runs a different
js-clientthan UI-16.7.So I merged 16.7 into my fork… and everything WORKS.
Thank you - that was helpful.
[I also set up Drone. Yes, it builds very fast.]
**
2 - Perhaps “LEMMY_DATABASE_URL” shows an obsolete value in the config docs:
- It is listed as -
postgres://lemmy:pw@LEMMY_DB:5432/lemmy - And perhaps should be -
postgres://lemmy:pw@POSTGRES:5432/lemmy
That 2nd string worked for me anyway - on an ansible install. (the former gives a 404 fetch error).
**
Thank you very much again.
Lemmy is running smooth and looking great.
I hope you are doing alright.
- It is listed as -
Are you using nginx from a docker container too? I think it’s most likely that whatever port you set up for reverse proxying the UI is incorrect. To kind of test this, you can try changing the UI’s port. If the ports are mismatched you should get the bad gateway error again.
NGINX was setup by the ansible install (it is running directly on the VPS).
The reverse-proxy ports were chosen by the ansible install. They work correctly when running the default lemmy-ui.
I have not modified anything in the ‘Lemmy-UI fork’ code (only added the docker-image.yml build file on github).
I have not modified anything on the VPS (other than the Environment Variables in docker-compose.yml, listed above).
When I list docker containers, there is no Port mapped to the ‘New-UI’ image container.
However, when running the ‘default lemmy-UI’ image container, the Port is mapped to 127.0.0.1:15153->1234/tcp
It seems I must create a new Container, using the ‘New-UI’ image, and map the Port to 127.0.0.1:15153->1234/tcp (unless an Environment Variable can do it)
^ Now I have to figure out that exact docker command. (because
docker run -d -p 127.0.0.1:15153:1234 [ImageID]does not successfully create a mapped container.)That docker run command looks correct. What is the error message you are getting? My guess is that soemthing else is already occupying your system’s port 15153.
It’s fixed!
The issue was - the ‘New UI’ docker image was automatically building for AMD64, but the Linux server is an ARM64/v8.
I had to add QEMU and multi-platform build commands to the docker-image.yml file (in Github Actions).
This creates an additional docker image for ARM64 machines, which loads successfully.
This was discovered by manually building a docker container, and receiving the following message:
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requestedThank you very much for replying KSYNWA! It helped me target the right area to find the problem.
I’m sure I’ll be back with another question, as I’m kinda wingin it over here.
