Google Compute Engine VM实例：VFS：无法在未知块上安装root fs

时间：2015-12-21 23:27:46

标签： filesystems google-compute-engine boot disk

由于发生了一些启动订单问题，我在Google Compute Engine上的实例无法启动。

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

我的问题：

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

    3. 日志 

      

    [    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)

3 个答案:

答案 0 :(得分：4)

原因是什么？

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

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

  

修改：Google云支持的新响应。

     

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

     

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

1。 ＆＃34;我在托管某些网站时如何处理这些问题？＆＃34;

我的第一直觉是建议使用AWS而不是GCE。但是，GCE 更便宜。在执行 任何 升级之前，请确保拍摄快照，然后尝试重新启动服务器以查看升级是否破坏了任何内容。

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

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

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

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

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

  3. 删除损坏的实例。

    重要提示：请确保不要选择删除引导磁盘的选项。否则，磁盘将永久删除!!

  4. 启动新的临时实例。

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

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

    7. 在临时实例中：

    # 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中的第二个答案（基于终端的答案）来清除其他内核。

    注意：确保不要使用！

    清除启动的内核

答案 1 :(得分：1)

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

我不确定你是如何陷入这种情况的，但是如果有其他信息（请参阅上面的评论）以便能够理解触发此问题的原因，那将会很不错。

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

附加并装入磁盘

假设您在删除实例时没有删除原始磁盘，您只需从另一个VM安装此磁盘即可从中读取数据。要做到这一点：

  1. attach the disk to another VM instance，例如，

    gcloud compute instances attach-disk $INSTANCE --disk $DISK

  2. 挂载磁盘：

    sudo mkdir -p /mnt/disks/[MNT_DIR]

    sudo mount [OPTIONS] /dev/disk/by-id/google-[DISK_NAME] /mnt/disks/[MNT_DIR]

    注意：您需要替换适当的值：

    • MNT_DIR：目录
    • OPTIONS：适合您的磁盘和文件系统的选项
    • DISK_NAME：将磁盘附加到VM后的磁盘ID

    3. 卸载和分离磁盘

    完成磁盘使用后，请执行以下步骤：

    注意：在分离非根磁盘之前，请先卸载磁盘。拆卸已安装的磁盘可能会导致I / O操作不完整和数据损坏。

    1. 卸载磁盘

      sudo umount /dev/disk/by-id/google-[DISK_NAME]

    2. detach the disk from the VM：

      gcloud compute instances detach-disk $INSTANCE --device-name my-new-device

答案 2 :(得分：1)

在我的情况下grub（/boot/grub/grub.cfg）第一个menuentry（3.19.0-51-generic）缺少一个initrd条目而无法启动。

进一步调查后，查看特定内核的dpkg，将其标记为失败和未配置

dpkg -l | grep 3.19.0-51-generic
     iF  linux-image-3.19.0-51-generic       3.19.0-51.58~14.04.1         
     iU  linux-image-extra-3.19.0-51-generic 3.19.0-51.58~14.04.1

这完全源于Google提供的Ubuntu映像，启用了无人值守升级。出于某种原因，initrd在构建时被杀死，而其他东西出现并运行update-grub2。

 unattended-upgrades-dpkg_2016-03-10_06:49:42.550403.log:update-initramfs: Generating /boot/initrd.img-3.19.0-51-generic
 Killed
 E: mkinitramfs failure cpio 141 xz -8 --check=crc32 137
 unattended-upgrades-dpkg_2016-03-10_06:49:42.550403.log:update-initramfs: failed for /boot/initrd.img-3.19.0-51-generic with 1.

解决即时问题。 

 dpkg --force-confold --configure -a

虽然理论上的无人值守升级是一个好主意，但默认情况下启用它可能会产生无人值守的后果。

相关问题
最新问题