不同步：VFS：无法在未知块（0,0）上安装根文件系统

Question 1

VFS: unable to mount root fs on unknown-block(0 0)意味着内核无法挂载根文件系统。造成这种情况的常见原因有两个：

内核不支持设备上的文件系统。如果您编译了自己的内核，这通常是因为您指定文件系统驱动程序应构建为模块而不是内核的本机部分；如果您使用发行版的内核，这通常是因为您为根文件系统选择了一种奇特的格式。无论哪种情况，都不要这样做。
传递给内核的根设备名称是错误的。这个问题可能很难修复：我发现的最好方法是从引导加载程序修改内核命令行，对参数root=应该是什么样子进行有根据的猜测，直到找到可行的东西。

Answer

VFS: unable to mount root fs on unknown-block(0 0)意味着内核无法挂载根文件系统。造成这种情况的常见原因有两个：

内核不支持设备上的文件系统。如果您编译了自己的内核，这通常是因为您指定文件系统驱动程序应构建为模块而不是内核的本机部分；如果您使用发行版的内核，这通常是因为您为根文件系统选择了一种奇特的格式。无论哪种情况，都不要这样做。
传递给内核的根设备名称是错误的。这个问题可能很难修复：我发现的最好方法是从引导加载程序修改内核命令行，对参数root=应该是什么样子进行有根据的猜测，直到找到可行的东西。

Question 2

基于内核消息的完整诊断过程

通过使用这个QEMU 仿真设置我尝试为每种可能的故障类型提供最少的示例，以帮助您调试问题。

在这个简单的设置中，QEMU 通过以下方式模拟系统：

代表真实硬件的硬盘或 SDD 的单个 virtio 磁盘
该 virtio 磁盘中有一个原始的未分区的 ext4 映像。在正常操作中，该设备将出现在/dev/vda（v是 virtio 的指示符字母，如果已分区，则分区将为/dev/vda1、/dev/vda2等）

您可能遇到的错误是：

Linux 无法从磁盘读取字节。

这可能是因为磁盘损坏，或者是因为您没有将 Linux 配置为能够读取该硬件类型。

在我的 QEMU 案例中，我可以通过删除允许内核读取该 virtio 磁盘的关键选项来重现此情况：
```
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_PCI=y
```
产生的错误消息看起来像这样
```
<4>[    0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
<4>[    0.542035] Please append a correct "root=" boot option; here are the available partitions:
<0>[    0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
```
所以这里 Linux 告诉我们它根本无法从 vda 读取：VFS: Cannot open root device "vda" or unknown-block(0,0): error -6。

然后，Please append a correct "root=" boot option; here are the available partitions:它给出了它可以读取的分区列表。

然而，在我们的例子中，列表是空的，因为下一行完全不相关。
Linux 可以从磁盘读取字节，但它不理解文件系统以从中读取文件。

这通常是因为您没有配置内核来读取该文件系统类型。

我可以通过删除内核读取 ext4 文件系统的能力来解决这种情况：
```
CONFIG_EXT4_FS=y
```
删除后，错误消息为：
```
<4>[    0.585296] List of all partitions:
<4>[    0.585913] fe00          524288 vda
<4>[    0.586123]  driver: virtio_blk
<4>[    0.586471] No filesystem could mount root, tried:
<4>[    0.586497]  squashfs
<4>[    0.586724]
<0>[    0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0)
```
所以Linux告诉我们它vda通过使用设备读取磁盘成功找到了分区virtio_blk。

但随后，它无法读取该分区。它尝试过squashfs，这是我们启用的唯一其他文件系统，但这不起作用，因为我们有一个 ext4 分区。
您传递了错误的root=内核命令行选项。

这题很简单，只要答对就可以了！内核甚至为您提供了它所知道的列表！

例如，如果我们传递一个错误：
```
root=/dev/vda2
```
它甚至不存在，内核给出以下类型的错误：
```
<4>[    0.608475] Please append a correct "root=" boot option; here are the available partitions:
<4>[    0.609563] fe00          524288 vda
<4>[    0.609723]  driver: virtio_blk
<0>[    0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2)
```
清理告诉我们“嘿：没有vda2，但是有vda！”

这个例子也很好地阐明了之前案例中(0,0),(254,0)和的(254,2)含义：
- (0,0)：第一个数字0表示根本无法从磁盘读取
- (254,2): 254 是分配给磁盘的一些 ID。2是具有该 ID 的分区，如中所示/dev/vda2。分区0表示原始的未分区分区，如中所示/dev/vda。

在 Linux 5.4.3 上测试。

Answer

基于内核消息的完整诊断过程

通过使用这个QEMU 仿真设置我尝试为每种可能的故障类型提供最少的示例，以帮助您调试问题。

在这个简单的设置中，QEMU 通过以下方式模拟系统：

代表真实硬件的硬盘或 SDD 的单个 virtio 磁盘
该 virtio 磁盘中有一个原始的未分区的 ext4 映像。在正常操作中，该设备将出现在/dev/vda（v是 virtio 的指示符字母，如果已分区，则分区将为/dev/vda1、/dev/vda2等）

您可能遇到的错误是：

Linux 无法从磁盘读取字节。

这可能是因为磁盘损坏，或者是因为您没有将 Linux 配置为能够读取该硬件类型。

在我的 QEMU 案例中，我可以通过删除允许内核读取该 virtio 磁盘的关键选项来重现此情况：
```
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_PCI=y
```
产生的错误消息看起来像这样
```
<4>[    0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
<4>[    0.542035] Please append a correct "root=" boot option; here are the available partitions:
<0>[    0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
```
所以这里 Linux 告诉我们它根本无法从 vda 读取：VFS: Cannot open root device "vda" or unknown-block(0,0): error -6。

然后，Please append a correct "root=" boot option; here are the available partitions:它给出了它可以读取的分区列表。

然而，在我们的例子中，列表是空的，因为下一行完全不相关。
Linux 可以从磁盘读取字节，但它不理解文件系统以从中读取文件。

这通常是因为您没有配置内核来读取该文件系统类型。

我可以通过删除内核读取 ext4 文件系统的能力来解决这种情况：
```
CONFIG_EXT4_FS=y
```
删除后，错误消息为：
```
<4>[    0.585296] List of all partitions:
<4>[    0.585913] fe00          524288 vda
<4>[    0.586123]  driver: virtio_blk
<4>[    0.586471] No filesystem could mount root, tried:
<4>[    0.586497]  squashfs
<4>[    0.586724]
<0>[    0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0)
```
所以Linux告诉我们它vda通过使用设备读取磁盘成功找到了分区virtio_blk。

但随后，它无法读取该分区。它尝试过squashfs，这是我们启用的唯一其他文件系统，但这不起作用，因为我们有一个 ext4 分区。
您传递了错误的root=内核命令行选项。

这题很简单，只要答对就可以了！内核甚至为您提供了它所知道的列表！

例如，如果我们传递一个错误：
```
root=/dev/vda2
```
它甚至不存在，内核给出以下类型的错误：
```
<4>[    0.608475] Please append a correct "root=" boot option; here are the available partitions:
<4>[    0.609563] fe00          524288 vda
<4>[    0.609723]  driver: virtio_blk
<0>[    0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2)
```
清理告诉我们“嘿：没有vda2，但是有vda！”

这个例子也很好地阐明了之前案例中(0,0),(254,0)和的(254,2)含义：
- (0,0)：第一个数字0表示根本无法从磁盘读取
- (254,2): 254 是分配给磁盘的一些 ID。2是具有该 ID 的分区，如中所示/dev/vda2。分区0表示原始的未分区分区，如中所示/dev/vda。

在 Linux 5.4.3 上测试。

Question 3

VFS：无法在未知块（0 0）上挂载根文件系统_ _ _

长按电源按钮关闭笔记本电脑。
选择“高级”选项。
选择通用的最低版本（“恢复模式”）
点击“清理”“尝试释放可用空间”
然后“恢复”“恢复正常启动”

Answer

VFS：无法在未知块（0 0）上挂载根文件系统_ _ _

长按电源按钮关闭笔记本电脑。
选择“高级”选项。
选择通用的最低版本（“恢复模式”）
点击“清理”“尝试释放可用空间”
然后“恢复”“恢复正常启动”

Question 4

@HasanQ 最接近正确答案，但仍然不完整。

它与基于 Arch 的发行版有关，不是从内核中加载 intel-ucode 和 amd-ucode，而是单独执行它，如果您按“e”进行编辑，可以从 Grub 菜单中的相应条目轻松看出这一点并检查启动参数 - 查看底线。

这种情况发生在基于 Debian 的发行版（例如 Mint、Ubuntu）、基于 RPM 的发行版（例如 Fedora、Mageia）和基于 Gentoo 的发行版（Calulate 和 Sabayon）。我还没有用 Slackware 尝试过。您不必使用基于 Arch 的引导加载程序。

您可以创建一个文件，通常custom.cfg可以将其放置在任何地方- 无需更新 grub，只需重新启动并选择菜单底部的条目即可。grub.cfg/boot/grub

您可以在以下位置阅读相关内容：Linux 点组织或努力论坛。

在其他地方，在安装了 Manjaro 或其他 Arch 以及其他发行版，然后是内核恐慌，我写了以下内容：

如果您的计算机上仅运行 Manjaro（或其他基于 Arch 的发行版），甚至与 Windows 进行双引导，然后选择安装其他不基于 Arch 的发行版，那么本文适合您。

如果您正在双启动或多启动甚至一个不基于 Arch 的 Linux，那么您很可能会遇到内核恐慌。

它会在非 Arch 发行版上执行更新和升级后发生，这足以导致该发行版占据主分区的位置，即 Grub 菜单的顶部。

本文仅适用于 GRUB，尽管我有兴趣听取 rEFInd 用户和其他引导加载程序用户的意见。

更新和升级的软件包将按顺序生成此更改，包括但不限于以下内容的某些组合：

你的内核

Grub、grub-efi、grub-pc、grub-signed 等

垫片，垫片签名

一些主要固件更新

其他（你会找到他们，或者他们会找到你！）

您将重新启动计算机，另一个发行版现在将位于首位并且工作正常，然后您按下键选择 Manjaro 并...

内核恐慌

内核恐慌会将您转储到黑白（tty 样式）屏幕，输出类似于以下内容
Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0)
接下来是 CPU 参考、硬件名称、调用跟踪、内核偏移量，并以
---[ end Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0) ]---
除了断电并重新启动之外，您无法退出或得到响应，而且这次不选择 Manjaro。

据说，防止这种情况的唯一方法是确保 Manjaro（或其他基于 Arch 的）Grub 处于控制之中。

事实并非如此。

只需生成一个名为的文件custom.cfg并将其存储在您的 ( /boot/grub) 文件夹中（可能/boot/grub2位于某些发行版系列中），一旦您重新启动，该条目就会出现在 Grub 菜单的末尾。无需更新 Grub。去做就对了。

我现在将向您展示如何执行此操作。

我会用最简短的方式来总结它，因为我知道有用户需要这个，然后我将为那些普遍真正感兴趣的人填写更多细节。所以它可能是分期付款的线程。

准备

如果您是 Timeshift、BackInTime、Snapper 或类似系统恢复工具的用户，请首先为您正在运行的任何正在运行的操作系统拍摄快照/映像并对其进行保护。

获取 Endeavor 或其他基于 Arch 的发行版的根分区的 UUID 并将其放在手边，您需要输入它。这可以通过多种方法获得，包括但不限于以下方法：

在Gparted中，右键单击根分区，单击信息

在终端使用blkid | grep -i <label of distro if labelled>

检查一下/etc/fstab

其他方式

决定要使用哪种文本编辑器（CLI 还是 GUI）来创建小文本文件，并注意生成的文件需要放置在 ( ) 中，或者具体地说，放置在存储文件的/boot/grub文件夹中。grub.cfg

这将需要 root 权限，例如 sudo，或者假设 root。到非 Endeavour、非基于 Arch 的发行版（例如启动到 Linux Mint），该发行版位于 Grub 菜单的主分区（顶部）位置。

引导至非 Endeavour、非基于 Arch 的发行版（例如引导至 Linux Mint），该发行版位于 Grub 菜单的主分区（顶部）位置。

脚步

典型的 EXT4 UUID 将采用 32 位数字和字母字符的格式，结构如下（8 然后 4 然后 4 然后 4 然后 12，用破折号分隔）
7b52a802-aa6d-4aa2-aab5-5dffbe6833c6 
对于这个练习，我将使用
nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn 
然后通过复制/粘贴从准备步骤 2.1.-4 中获得的结果来替换该值。多于。
要么使用touch创建文件custom.cfg，然后使用您最喜欢的文本编辑器，或者我只是使用nano如下
sudo nano custom.cfg

并输入此文本，其中 n 的字符串是您的 Endeavor 或其他基于 Arch 的发行版的根分区的 UUID
menuentry "Manjaro - configfile" { 
insmod part_gpt 
part part_msdos 
insmod ext2 
search --no-floppy --fs-uuid --set=root nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn
configfile /boot/grub/grub.cfg
}
第一行引号中的部分是您的选择，如果您愿意，您可以将其称为“我亲爱的Manjaro”。

除此之外，请确保语法完全匹配，包括这两个大括号。
保存并退出，或退出并保存文件，将其放在 ( /boot/grub) 中或grub.cfg文件所在的任何位置。

重启（无需更新grub）
如果您正确地遵循了上述步骤，当您看到 GRUB 菜单时，它的末尾将会有一个附加条目，说明第一行中的内容。这是您 Manjaro 或您选择的基于 Arch 的发行版的新入口点。

在有序的 GRUB 菜单列表中仍然会有 Manjaro 的另一个条目，但如果你选择它，你仍然会遇到内核恐慌，所以练习选择最后一个。

Answer