Google Compute Engine VM实例：VFS：无法在未知块上挂载根fs

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

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

我的问题：

托管一些网站时如何处理这些问题？

如何从旧磁盘恢复数据？

日志

  

    [0.348577]密钥类型可信注册
    [0.349232]密钥类型已加密注册
    [0.349769] AppArmor：启用了AppArmor sha1策略哈希
    [0.350351] ima：未找到TPM芯片，正在激活TPM旁路！
    [0.351070] EVM：HMAC属性：0x1
    [0.351549]幻数：11：333：138
    [0.352077]块ram3：哈希匹配
    [0.352550] rtc_cmos 00:00：将系统时钟设置为2015-12-19 17:06:53 UTC（1450544813）
    [0.353492] BIOS EDD设备v0.16 2004年6月25日，找到0个设备
    [0.354108] EDD信息不可用。
    [0.536267]输入：AT Translated Set 2键盘为/ devices / platform / i8042 / serio0 / input / input2
    [0.537862] md：在自动检测之前，等待所有设备可用
    [0.538979] md：如果您不使用raid，请使用raid = noautodetect
    [0.539969] md：自动检测RAID阵列。
    [0.540699] md：已扫描0，并添加了0个设备。
    [0.541565] md：自动运行...
    [0.542093] md：...自动运行完成。
    [0.542723] VFS：无法打开根设备“ sda1”或未知块（0,0）：错误-6
    [0.543731]请附加正确的“ root =”引导选项；这是可用的分区：
    [0.545011]内核崩溃-不同步：VFS：无法在未知块（0,0）上安装根fs
    [0.546199] CPU：0 PID：1 Comm：swapper / 0未污染3.19.0-39-generic＃44〜14.04.1-Ubuntu
    [0.547579]硬件名称：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]通话跟踪：
    [0.549004] [] dump_stack + 0x45 / 0x57
    [0.549004] []恐慌+ 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]内核偏移：0xffffffff81000000中的0x0（重定位范围：0xffffffff80000000-0xffffffffbfffffff）
    [0.549004] --- [结束内核崩溃-不同步：VFS：无法在未知块（0,0）上安装根fs

Nostalg.io.. 5

是什么原因造成的？

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

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

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

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

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

1.“托管某些网站时如何处理这些问题？”

我的第一个直觉是建议使用AWS而不是GCE。然而，GCE 是更便宜。在进行任何升级之前，请确保已拍摄快照，然后尝试重新引导服务器以查看升级是否中断了任何事情。

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

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

经过多次来回电子邮件，我终于收到了支持人员的回复，使我得以解决了该问题。请注意，您将必须进行更改以匹配您的唯一VM。

如果需要回滚以下任何更改，请先对磁盘进行快照。

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

删除损坏的实例。

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

启动一个新的临时实例。

将损坏的磁盘（将显示为/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文件）。

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

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

1> Nostalg.io..：

---

是什么原因造成的？

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

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

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

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

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

1.“托管某些网站时如何处理这些问题？”

我的第一个直觉是建议使用AWS而不是GCE。然而，GCE 是更便宜。在进行任何升级之前，请确保已拍摄快照，然后尝试重新引导服务器以查看升级是否中断了任何事情。

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

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

经过多次来回电子邮件，我终于收到了支持人员的回复，使我得以解决了该问题。请注意，您将必须进行更改以匹配您的唯一VM。

如果需要回滚以下任何更改，请先对磁盘进行快照。

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

删除损坏的实例。

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

启动一个新的临时实例。

将损坏的磁盘（将显示为/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文件）。

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

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