Google Compute 实例不会挂载永久性磁盘，维持约 100% 的 CPU

Question

在我的网络服务器的一些日常使用过程中（通过 WordPress 保存帖子），我的实例突然上升到 400% 的 CPU 使用率，并且不会降到 100% 以下。重启和停止/启动实例并没有改变任何东西。

查看我的串行输出的最后一位：

[    0.678602] md: Waiting for all devices to be available before autodetect
[    0.679518] md: If you don't use raid, use raid=noautodetect
[    0.680548] md: Autodetecting RAID arrays.
[    0.681284] md: Scanned 0 and added 0 devices.
[    0.682173] md: autorun ...
[    0.682765] md: ... autorun DONE.
[    0.683716] VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
[    0.685298] Please append a correct "root=" boot option; here are the available partitions:
[    0.686676] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    0.688489] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-30-generic #34~14.04.1-Ubuntu
[    0.689287] Hardware name: Google Google, BIOS Google 01/01/2011
[    0.689287]  ffffea00008ae400 ffff880024ee7db8 ffffffff817af477 000000000000111e
[    0.689287]  ffffffff81a7c6c0 ffff880024ee7e38 ffffffff817a9338 ffff880024ee7dd8
[    0.689287]  ffffffff00000010 ffff880024ee7e48 ffff880024ee7de8 ffff880024ee7e38
[    0.689287] Call Trace:
[    0.689287]  [<ffffffff817af477>] dump_stack+0x45/0x57
[    0.689287]  [<ffffffff817a9338>] panic+0xc1/0x1f5
[    0.689287]  [<ffffffff81d3e5f3>] mount_block_root+0x210/0x2a9
[    0.689287]  [<ffffffff81d3e822>] mount_root+0x54/0x58
[    0.689287]  [<ffffffff81d3e993>] prepare_namespace+0x16d/0x1a6
[    0.689287]  [<ffffffff81d3e304>] kernel_init_freeable+0x1f6/0x20b
[    0.689287]  [<ffffffff81d3d9a7>] ? initcall_blacklist+0xc0/0xc0
[    0.689287]  [<ffffffff8179fab0>] ? rest_init+0x80/0x80
[    0.689287]  [<ffffffff8179fabe>] kernel_init+0xe/0xf0
[    0.689287]  [<ffffffff817b6d98>] ret_from_fork+0x58/0x90
[    0.689287]  [<ffffffff8179fab0>] ? rest_init+0x80/0x80
[    0.689287] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    0.689287] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

（不确定这是否明显，但我使用的是标准的 Ubuntu 14.04 映像）

我已经尝试拍摄快照并将它们挂载到新实例上，现在我什至删除了实例并将磁盘挂载到新实例上，仍然是同样的问题和完全相同的串行输出。

我真的希望我的数据没有被彻底破坏。不确定是否有人对从永久性磁盘恢复数据有任何建议？

请注意，Google Compute Engine VM instance: VFS: Unable to mount root fs on unknown-block 接受的答案对我不起作用。

Answer 1

我在另一个问题上发布了这个，但是这个问题的措辞更好，所以我会在这里重新发布。

这是什么原因？

这是百万美元的问题。在检查了我的 GCE VM 后，我发现安装了 14 个不同的内核，占用了数百 MB 的空间。大多数内核没有对应的 initrd.img 文件，因此无法启动（包括 3.19.0-39-generic）。

我当然从来没有四处尝试安装随机内核，一旦删除，它们就不再显示为可用升级，所以我不确定发生了什么。说真的，发生了什么？

编辑：来自 Google Cloud 支持的新回复。

我收到了另一个令人不安的回复。这可以解释额外的错误内核。

“在极少数情况下，需要将 VM 从一个物理主机迁移到另一个物理主机。在这种情况下，Google 可能会应用内核升级和安全补丁。”

如何恢复您的实例...

在来回发送了几封电子邮件后，我终于收到了支持部门的回复，让我能够解决问题。请注意，您必须进行更改以匹配您独特的虚拟机。

1. 首先拍摄磁盘快照，以防我们需要回滚以下任何更改。

2. 编辑损坏实例的属性以禁用此选项：“删除实例时删除启动盘”

3. 删除损坏的实例。

   重要提示：确保不要选择删除启动盘的选项。否则，磁盘将被永久删除！！

4. 启动一个新的临时实例。

5. 将损坏的磁盘（这将显示为/dev/sdb1）附加到临时实例

6. 启动临时实例时，请执行以下操作：

在临时实例中：

# Run fsck to fix any disk corruption issues
$ sudo fsck.ext4 -a /dev/sdb1

# Mount the disk from the broken vm
$ sudo mkdir /mnt/sdb
$ sudo mount /dev/sdb1 /mnt/sdb/ -t ext4

# Find out the UUID of the broken disk. In this case, the uuid of sdb1 is d9cae47b-328f-482a-a202-d0ba41926661
$ ls -alt /dev/disk/by-uuid/
lrwxrwxrwx. 1 root root 10 Jan 6 07:43 d9cae47b-328f-482a-a202-d0ba41926661 -> ../../sdb1
lrwxrwxrwx. 1 root root 10 Jan 6 05:39 a8cf6ab7-92fb-42c6-b95f-d437f94aaf98 -> ../../sda1

# Update the UUID in grub.cfg (if necessary)
$ sudo vim /mnt/sdb/boot/grub/grub.cfg

注意：这里 ^^^ 是我偏离支持说明的地方。

我没有将所有引导条目修改为设置root=UUID=[uuid character string]，而是查找了所有设置root=/dev/sda1 的条目并将其删除。我还删除了所有没有设置initrd.img 文件的条目。在我的例子中，具有正确参数的顶级引导条目最终是 3.19.0-31-generic。但你的可能不一样。

# Flush all changes to disk
$ sudo sync

# Shut down the temporary instance
$ sudo shutdown -h now

最后，从临时实例中分离 HDD，并基于 fixed 磁盘创建一个新实例。它有望启动。

假设它确实启动了，你有很多工作要做。如果您的未使用内核数量是我的一半，那么您可能需要清除未使用的内核（尤其是因为有些可能缺少相应的 initrd.img 文件）。

我在this askubuntu question 中使用了第二个 答案（基于终端的答案）来清除其他内核。

注意：确保不要清除启动时使用的内核！

Answer 2

为了恢复您的数据，您需要创建一个可以 ssh 的全新实例，并将损坏的磁盘作为辅助磁盘附加到该实例。更多信息可以在this article 中找到。我建议在附加损坏的磁盘之前对其进行快照，以进行备份。