This one is likely to work. You can start that image with e.g. docker start b5f2a8a39709 .
(You might also want to trim some of those older images - there’s potentially a large chunk of disk space that can be recovered!)
2 Likes
Getting: Error response from daemon: No such container: b5f2a8a39709
Thanks. Also, my backup procedures copy ALL files from the system. There are likely more recent images there if I knew where to look and where to copy them.
My apologies for interrupting the workaround, but we are going to migrate to another server, which was a challenge on its own because it was a dedicated server and we just renewed the contract for an entire year last June.
Perhaps it would be nice if the Discourse team issues a warning for people who run it on servers that aren’t supported anymore. To find it out the way we did is VERY unpleasant. (three users with the same issue, we’re talking about servers, they don’t get renewed at the same speed as Laptops do.)
1 Like
I want it to be clear this was not an intentional change.
We also do not have direct access to hardware this old and need to rely on some community assistance here to help determine what exactly is going wrong.
Once we know for sure this is a compilation problem with the gem itself, we can take action.
3 Likes
@here
Adding a top level key on the app.yml file with
base_image: discourse/base:2.0.20220621-0049-slim
Should work around the issue, albeit will slow down rebuilds a bit.
3 Likes
That’s fair, but such servers still are being offered by providers around the world as low-entry servers.
For a lot of smaller Open source projects, such servers are ideal, price-wise and often they cannot afford an Intel Xeon or AMD Ryzen with 32 GB RAM.
I completely understand that you don’t have the hardware to test the software on, but from the communication in this thread, it was established by us and then there wasn’t any reaction at all.
A simple sorry, we are going to look into this would be sufficient in this case, instead, you let us hang there.
1 Like
Testing now with this change.
Build appears to fail the same way.
This was with the change to containers/app.yml, adding:
base_image: discourse/base:2.0.20220621-0049-slim
near the top.
1 Like
That means the issue is not that we ship a pre-compiled version of the gem, but that the upstream gem can’t compile on those old CPUs.
We have raised issue #789 against the oj gem.
2 Likes
Understood. I’d like to restore one of my recent docker images – from my rsync backups. Is there a procedure you can point me at to locate these and restore/start one? Thanks!
Have you tried a ./launcher start app ?
1 Like
If this one doesn’t work, try the other method I detailed for rebuilding from the last-working commit.
3 Likes
Yeah. That gets the web server running, but you can’t actually access any threads, they just spin.
This will not help.
The problem is that the updated gem doesn’t check if the instruction is supported by the CPU before using it.
It will help getting the Discourse instance back up-and-running as it installs the previous/working gem version (proved by what I did to get Bryan’s instance back), but yes - any further update (via admin/upgrade) will trigger the same issue again.
1 Like
I’m not having any luck with a new build or getting the previous instance running yet, so since the weekend is coming up I may sit on this until next week in hopes that the situation can be fixed from the gem side …
Which procedure was this? I’m admittedly a bit confused now trying to follow the various ideas on this thread. Thanks!
The second part of this post:
1 Like
I’ll give this a try. Thanks.
Another possible workaround is adding the following to the app.yml
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
3 Likes
I assume updates would still be unsafe after this, correct? Doing the build on the older commit currently.