这个很可能会起作用。你可以用 docker start b5f2a8a39709 来启动这个镜像。
（你可能还想清理掉一些旧的镜像——这可能会回收大量的磁盘空间！）
2 个赞
收到：守护进程的错误响应：未找到容器：b5f2a8a39709
谢谢。另外，我的备份程序会复制系统上的所有文件。如果我知道在哪里查找和复制它们，那里可能会有更新的镜像。
抱歉打断了工作流程，但我们要迁移到另一台服务器。这本身就是一个挑战，因为那是一台专用服务器，我们刚在去年六月续签了一整年的合同。
也许 Discourse 团队可以给那些在不再受支持的服务器上运行的用户发出警告。以我们发现的方式找出问题是非常令人不快的。（有三位用户遇到了同样的问题，我们说的是服务器，它们的续订速度不像笔记本电脑那么快。）
1 个赞
3 个赞
@here
在 app.yml 文件中添加一个顶级键，并使用
base_image: discourse/base:2.0.20220621-0049-slim
应该可以解决该问题，尽管会稍微减慢重建速度。
3 个赞
这很公平，但世界各地的提供商仍将此类服务器作为低入门级服务器提供。
对于许多小型开源项目来说，此类服务器在价格方面是理想的选择，而且它们通常负担不起拥有 32 GB RAM 的 Intel Xeon 或 AMD Ryzen。
我完全理解您没有硬件来测试该软件，但根据此线程中的沟通，我们已经确立了这一点，然后根本没有做出任何反应。
在这种情况下，一句简单的“抱歉，我们会调查的”就足够了，但您却让我们一直等待。
1 个赞
正在用此更改进行测试。
构建似乎以相同的方式失败。
这是通过对 containers/app.yml 进行更改，在顶部附近添加：
base_image: discourse/base:2.0.20220621-0049-slim
1 个赞
这意味着问题不在于我们分发预编译版本的 gem，而在于上游 gem 无法在那些旧的 CPU 上进行编译。
我们已经针对 oj gem 提出了 issue #789。
2 个赞
好的。我想恢复我最近的一个 Docker 镜像——从我的 rsync 备份中。您能提供一个关于如何查找这些镜像并恢复/启动一个镜像的步骤吗？谢谢！
你试过 ./launcher start app 吗？
1 个赞
如果这个不行，请尝试我详细介绍的从上一个正常提交重建的另一种方法。
3 个赞
是的。这样就可以运行 Web 服务器了，但你实际上无法访问任何线程，它们只会空转。
这没有帮助。
问题在于，更新后的 gem 在使用指令之前，不会检查该指令是否受 CPU 支持。
这有助于使 Discourse 实例恢复运行，因为它会安装之前的/可用的 gem 版本（正如我为恢复 Bryan 的实例所做的那样），但是的——任何进一步的更新（通过 admin/upgrade）都会再次触发相同的问题。
1 个赞
我无法成功构建新版本或运行之前的实例，所以由于周末即将来临，我可能会等到下周再处理此事，希望问题能从 gem 方面得到解决……
这是哪个程序？我现在有点糊涂，试图理解这个帖子里的各种想法。谢谢！
此帖子的第二部分：
1 个赞
我会试试的。谢谢。
另一种可能的解决方法是在 app.yml 中添加以下内容：
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
3 个赞
我猜想在此之后更新仍然不安全，对吗？目前正在旧提交上进行构建。