Bug: Puter won't start anymore #1081
Comments
|
Works with |
|
What version were you running before? Or, are you using the latest changes on |
|
I've been running on |
|
Apparently it does, that's interesting. I'm at a bit of a loss for what causes this error, but of the |
|
I don't do anything inisde the container, I just start it :) Just remembered and checked: the container image builds on every push to main. |
|
@KernelDeimos I get the same problem with 2.5.0 now |
Also, I can't run |
|
So, I've done a I'm wondering if the |
|
I can't get the Docker image to build with the Dockerfile, for some reason. Trying to figure out why that is. |
|
Here's what I know so far:
The remaining questions right now are:
I'll keep this thread updated as I learn more. |
|
I think I found the source of the issue: The Next I'm going to try to find out:
|
|
Okay bad news, it still doesn't work. I'm going to make SNSService import lru-cache in a more flexible way so that both versions will work, but I really don't like this solution because getting the wrong version of lru-cache should never happen in the first place. I'm going to try more research and communication with other developers and see if I can get to the bottom of this. |
|
|
Running |
|
Wow, that's a lot of messages :-) I can verify that building the image locally also results in the same error, so it's something in the Docker image build that goes haywire... |
|
Ran into this error with 23-bookworm: On search, that led me to this comment: nodegit/nodegit#2006 (comment) Now trying with 20-bookworm and 20-alpine |
|
I'm getting a successful build on node20-alpine with the additional
|
|
Acutally, the latest The GUI doesn't fully work, but it's better than it was :) |
If you're able to reproduce this outside of a GitHub Action this is a really good step forward. I am unable to reprod when I build the image in this way: docker build -t foo .
docker run --rm -it fooAre you building the Dockerfile with a different method? |
That's the way I do it too. I just tried the build with the latest Dockerfile and it worked. |
Output from last run (completed 2 minutes ago) |
|
Are you still able to reprod the one that fails, maybe on an older version of the image? The image from ghcr with the additional Also, the line in our Dockerfile that runs |
Not sure, I will have to try that, but, unfortunately, that will not be until Tuesday. About to head out do a weekend away, no laptop allowed. I'll test that after I get back.
I've had that fail a few times in my "normal" build as well, so not sure if that's GH Actions related. We are using build actions that are pretty much the defacto standard for this, so fails do not necessarily relate to the action, but maybe more on how Docker runs stuff itself. Which leads me to the following: what do you run your Puter on? |
I'm going to raise a counterpoint here that I think is very important. If the build is more reliable on Debian and we solve issues by switching to Debian, that means we don't really understand how the build works; that makes Debian a magic block that holds everything up; not quite like the vertical beam in XKCD #2347, but maybe like the two more-sturdy pieces to the left of that. Most backend testing actually happens on Arch, which is (maybe) more similar to Alpine, but it's for those reasons that I want to prioritize reducing build time (which is really slow on GH as it is) and the size of the image. Luckily, I think I'm curious about the gui issue you mentioned earlier - were you able to solve that? Also, is |
I fully get your point. The advantage of using docker is that it's always fresh, which means it's reproducible. The disadvantage that brings is that it's sometimes hard to get things working initially, because you are running fresh. If that makes sense at all :-)
No , the GUI issue is still there.
Well, on my one laptop, I do need to use that, on the other laptop, I don't, so that's interesting as well. Let's not focus on that, as that seems to be a "me" problem. |
|
I've removed all data and my GUI is now working again. Maybe we should close this and create a different issue on the Docker build issues? |
Docker build seems okay now but I never go to know for sure what fixed it. I'll close this for now but please open a new issue if you run into this again. I imagine that soon we'll do a lot of additional testing with Docker builds to make sure it's easy and free of issues. |
|
Same error and docker |
|
I am also facing the same issue. I am installing first time through docker compose. What was the fix here? |
|
@liuxiawei - hi, thanks for reporting; please open a new issue. The only reason I saw your comment on a closed issue is because I happened to have the tab still open in a very old instance of Chromium. Also, when you're writing the new report, please keep in mind that this message does not indicate what the error is:
You'll need to post more log output and context so we can diagnose the issue. |
|
this shit never got solved. I validated the images. Removing removing all files is not a solution, also no fix. Have you ever verified it in a clean lab? For the mass, which actually need help and did not get it here. The tagged latest image is broken and wasn't updated since 30days, either switch to tag main or 2.4.2. The lru-cache issue is not corrected in latest. |
|
It now happens again in the latest image. The last row of log is |
Issue Description
I run puter via Docker, but it doesn't work anymore.
Not entirely sure when this happened, but this what happens:
Steps to reproduce
Use
docker composeto run:mainbranch of puterExpected behaviour
I expect it to work :)
Addition Information or Screenshots (if applicable)
No response
Deployment
npm run start)docker run)docker-compose)Puter version
No response
The text was updated successfully, but these errors were encountered: