# 恢复帮助 - 系统在午夜挂起

**URL:** https://meta.discourse.org/t/help-restoring-system-hung-at-midnight/229486
**Category:** Self-hosting
**Created:** [2022年六月9日 09:14 UTC](https://meta.discourse.org/t/help-restoring-system-hung-at-midnight/229486 "2022-06-09T09:14:20Z")
**Posts on this page:** 1
**Showing post:** 30

<div class="post-metadata">

### Author: ![spamless](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spamless/32/255876_2.png) [@spamless](https://meta.discourse.org/u/spamless)
#### Post date: [2022年六月13日 20:45 UTC](https://meta.discourse.org/t/help-restoring-system-hung-at-midnight/229486/30 "2022-06-13T20:45:46Z")

</div>

> [@RBoy](#):
>
> 好吧，至少我弄清楚了为什么我的服务器昨晚崩溃了（今天在完全重建后又崩溃了 ☹ ，详情请参见此主题：[Ubuntu 20.04 内核更新与 Docker 导致崩溃](https://meta.discourse.org/t/ubuntu-20-04-kernel-update-with-docker-causing-a-crash/229526)

我的 Oracle Cloud 服务器也发生了同样的情况。内核恐慌了，我也恐慌了。我以为我完蛋了。但在通过云控制台进行了大约六到八次重启后，其中一些是“拔掉插头”式重启，并且在等待了大约半小时后，服务器终于启动了足够长的时间让我编辑 grub.cfg 并恢复到之前的内核。

我因此得以保住我的实例。一天后，又有一个新的内核更新可用，那时我更加确信我的内核问题理论是正确的。然后我找到了错误描述来证实它。是的，相当糟糕。

我设计了一个我称之为“愚蠢的 Grub 技巧”的方法，我会找时间匿名发布，这样以后就可以避免这种灾难了。

祝你恢复顺利，@RBoy。我必须说，这个帖子让我想起了上周（是星期三吧？）我自己的那次差点灾难，让我胃里一阵翻腾。

顺便说一句，你说你重新获得了对旧服务器的访问权限。如果你仍然拥有它，或者能够再次访问——对我来说，这需要一些强制重启和一些等待——那么，进去再更新一次，因为有一个新的内核没有这个错误。或者恢复到之前的内核。

---

_[View the full topic](https://meta.discourse.org/t/help-restoring-system-hung-at-midnight/229486)._