首页 文章

Google Compute实例不会挂载持久磁盘,维持~100%的CPU

提问于
浏览
0

在我的网络服务器的一些例行使用期间(通过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对我不起作用 .

2 回答

  • 0

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

  • 1

    I posted this on another question, but this question is worded better, so I'll re-post it here.

    这是什么原因造成的?

    那是百万美元的问题 . 在检查了我的GCE VM之后,我发现有14个不同的内核安装了几百MB 's of space. Most of the kernels didn'有一个相应的 initrd.img 文件,因此不能启动(包括3.19.0-39-generic) .

    我当然没有试图安装随机内核,一旦删除,它们就不再出现可用的升级,所以我不确定发生了什么 . 说真的,发生了什么?

    编辑:Google Cloud支持的新响应 . 我收到了另一个令人不安的回应 . 这可以解释其他错误的内核 . “在极少数情况下,需要将VM从一个物理主机迁移到另一个物理主机 . 在这种情况下,Google可能会应用内核升级和安全补丁 . ”

    如何恢复您的实例......

    在几封来回的电子邮件之后,我终于收到了支持的回复,这让我可以解决这个问题 . 请注意,您必须更改内容以匹配您的唯一VM .

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

    • 编辑损坏实例的属性以禁用此选项: "Delete boot disk when instance is deleted"

    • 删除损坏的实例 .

    重要信息:请确保不要选择删除引导磁盘的选项 . 否则,磁盘将被永久删除!

    • 启动一个新的临时实例 .

    • 将损坏的磁盘(这将显示为 /dev/sdb1 )附加到临时实例

    • 启动临时实例时,请执行以下操作:

    在临时实例中:

    # 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从临时实例中分离出来,并根据固定磁盘创建一个新实例 . 它有希望启动 .

    假设它启动了,你还有很多工作要做 . 如果你的未使用内核数量是我的一半,那么你可能想要清除未使用的内核(特别是因为有些内核可能缺少相应的initrd.img文件) .

    我在this askubuntu question中使用 second 答案(基于终端的答案)来清除其他内核 .

    注意:确保不要清除启动的内核!

相关问题