在我的网络服务器的一些例行使用期间(通过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 回答
为了恢复数据,您需要创建一个可以ssh的全新实例,并将损坏的磁盘作为辅助磁盘附加到它 . 更多信息可以在this article中找到 . 我建议在附加之前拍摄损坏的磁盘的快照,以备份 .
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) .
我当然没有试图安装随机内核,一旦删除,它们就不再出现可用的升级,所以我不确定发生了什么 . 说真的,发生了什么?
如何恢复您的实例......
在几封来回的电子邮件之后,我终于收到了支持的回复,这让我可以解决这个问题 . 请注意,您必须更改内容以匹配您的唯一VM .
首先拍摄磁盘快照,以防我们需要回滚以下任何更改 .
编辑损坏实例的属性以禁用此选项: "Delete boot disk when instance is deleted"
删除损坏的实例 .
重要信息:请确保不要选择删除引导磁盘的选项 . 否则,磁盘将被永久删除!
启动一个新的临时实例 .
将损坏的磁盘(这将显示为
/dev/sdb1
)附加到临时实例启动临时实例时,请执行以下操作:
在临时实例中:
注意:这^^^是我偏离支持指令的地方 .
我没有修改所有引导条目以设置
root=UUID=[uuid character string]
,而是查找了设置root=/dev/sda1
并删除它们的所有条目 . 我还删除了没有设置initrd.img
文件的每个条目 . 在我的情况下,具有正确参数的顶部引导条目最终为 3.19.0-31-generic . 但你的可能会有所不同 .最后,将HDD从临时实例中分离出来,并根据固定磁盘创建一个新实例 . 它有希望启动 .
假设它启动了,你还有很多工作要做 . 如果你的未使用内核数量是我的一半,那么你可能想要清除未使用的内核(特别是因为有些内核可能缺少相应的initrd.img文件) .
我在this askubuntu question中使用 second 答案(基于终端的答案)来清除其他内核 .
注意:确保不要清除启动的内核!