filesystems - 谷歌计算引擎虚拟机实例 : VFS: Unable to mount root fs on unknown-block

Question

由于某些启动顺序问题，我在 Google Compute Engine 上的实例无法启动。

所以，我创建了另一个实例并重新配置了我的机器。

我的问题:

1. 我在托管某些网站时如何处理这些问题？
2. 如何从旧磁盘恢复数据？

日志

  

    [    0.348577] Key type trusted registered
    [    0.349232] Key type encrypted registered
    [    0.349769] AppArmor: AppArmor sha1 policy hashing enabled
    [    0.350351] ima: No TPM chip found, activating TPM-bypass!
    [    0.351070] evm: HMAC attrs: 0x1
    [    0.351549]   Magic number: 11:333:138
    [    0.352077] block ram3: hash matches
    [    0.352550] rtc_cmos 00:00: setting system clock to 2015-12-19 17:06:53 UTC (1450544813)
    [    0.353492] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
    [    0.354108] EDD information not available.
    [    0.536267] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
    [    0.537862] md: Waiting for all devices to be available before autodetect
    [    0.538979] md: If you don't use raid, use raid=noautodetect
    [    0.539969] md: Autodetecting RAID arrays.
    [    0.540699] md: Scanned 0 and added 0 devices.
    [    0.541565] md: autorun ...
    [    0.542093] md: ... autorun DONE.
    [    0.542723] VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
    [    0.543731] Please append a correct "root=" boot option; here are the available partitions:
    [    0.545011] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
    [    0.546199] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-39-generic #44~14.04.1-Ubuntu
    [    0.547579] Hardware name: Google Google, BIOS Google 01/01/2011
    [    0.548728]  ffffea00008ae140 ffff880024ee7db8 ffffffff817af92b 000000000000111e
    [    0.549004]  ffffffff81a7c7c8 ffff880024ee7e38 ffffffff817a976b ffff880024ee7dd8
    [    0.549004]  ffffffff00000010 ffff880024ee7e48 ffff880024ee7de8 ffff880024ee7e38
    [    0.549004] Call Trace:
    [    0.549004]  [] dump_stack+0x45/0x57
    [    0.549004]  [] panic+0xc1/0x1f5
    [    0.549004]  [] mount_block_root+0x210/0x2a9
    [    0.549004]  [] mount_root+0x54/0x58
    [    0.549004]  [] prepare_namespace+0x16d/0x1a6
    [    0.549004]  [] kernel_init_freeable+0x1f6/0x20b
    [    0.549004]  [] ? initcall_blacklist+0xc0/0xc0
    [    0.549004]  [] ? rest_init+0x80/0x80
    [    0.549004]  [] kernel_init+0xe/0xf0
    [    0.549004]  [] ret_from_fork+0x58/0x90
    [    0.549004]  [] ? rest_init+0x80/0x80
    [    0.549004] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
    [    0.549004] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Answer 1

这是什么原因？

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

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

Edit: New response from Google Cloud Support.

I received another disconcerting response. This may explain the additional, errant kernels.

"On rare occasions, a VM needs to be migrated from one physical host to another. In such case, a kernel upgrade and security patches might be applied by Google."

1。 “当我托管一些网站时，我该如何处理这些问题？”

我的第一 react 是推荐使用 AWS 而不是 GCE。但是，GCE 更便宜。在进行任何升级之前，请确保您拍摄快照，然后尝试重新启动服务器以查看升级是否有任何问题。

2。如何从旧磁盘恢复数据？

更好 - 如何恢复您的实例...

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

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 字符串]，而是查找了所有设置 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 中使用了 第二个 答案(基于终端的答案)清除其他内核。

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