Linux安装启动时找不到磁盘的第一个分区

Question 1

我的第一个猜测是原始系统中的存储控制器与 qemu 提供的存储控制器不同，因此 initrd 文件不包含运行虚拟存储控制器的正确模块。

默认的存储控制器qemu-system-x86_64似乎不是AHCI，而是经典的Intel PIIX3 IDE控制器。它需要ata_piix内核模块，而在任何使用 AHCI 作为最低基线的相当现代的物理系统的 initrd 中，内核模块都是不必要的。

因此，内核根本无法看到磁盘，引导过程也无法从 initrd 转换到真正的根文件系统。

GRUB 可以很好地识别磁盘，因为它使用 BIOS 例程来访问磁盘...并且由于 BIOS 是由 qemu 提供的，因此 BIOS 显然具有完全正确的例程来完成这项工作。

如果您可以访问虚拟机的命令提示符，请尝试以下命令：

dmesg | grep -e piix -e ahci -e " sd"

它应该显示与磁盘检测相关的任何消息：如果没有显示任何内容，则未检测到您的（虚拟）存储控制器，这使得无法检测虚拟磁盘。

要修复它，您可能必须访问常规系统中的磁盘映像：（如果/dev/loop0系统已在使用该磁盘映像，请改用免费循环设备）

losetup -P /dev/loop0 srv.sda

然后安装/dev/loop0p1到常规系统中合适的临时位置：

mkdir /mnt/opensuse
mount /dev/loop0p1 /mnt/opensuse

将必要的虚拟文件系统和 chroot 添加到磁盘映像的文件系统中，类似于从实时 Linux 介质引导物理系统时可能执行的操作：

mount --rbind /dev /mnt/opensuse/dev
mount --bind /proc /mnt/opensuse/proc
mount --bind /sys /mnt/opensuse/sys
chroot /mnt/opensuse

现在您应该能够在磁盘映像中重新创建 initrd/initramfs 文件。您没有在映像上指定 OpenSUSE 系统的版本，但经典命令可能是要使用的工具 - 或者它实际上可能是新版本可能使用的mkinitrd任何新工具（也许？）的兼容性别名。dracut

无论使用哪个工具在该版本的 OpenSUSE 中创建 initrd 文件，该工具很可能有一个选项来强制将特定内核模块包含在 initrd 中。阅读该工具的手册页以找到该选项，并使用它创建一个ata_piix包含该模块的新 initrd。（为了安全起见，请先将原始 initrd 文件移到一边。）

一旦您initrd在/boot映像的正确位置成功创建了一个新文件，就exit可以脱离 chroot 环境，umount执行之前执行的所有安装操作，并使用losetup -d /dev/loop0.现在您可以尝试再次启动映像，希望能够成功。

Answer

我的第一个猜测是原始系统中的存储控制器与 qemu 提供的存储控制器不同，因此 initrd 文件不包含运行虚拟存储控制器的正确模块。

默认的存储控制器qemu-system-x86_64似乎不是AHCI，而是经典的Intel PIIX3 IDE控制器。它需要ata_piix内核模块，而在任何使用 AHCI 作为最低基线的相当现代的物理系统的 initrd 中，内核模块都是不必要的。

因此，内核根本无法看到磁盘，引导过程也无法从 initrd 转换到真正的根文件系统。

GRUB 可以很好地识别磁盘，因为它使用 BIOS 例程来访问磁盘...并且由于 BIOS 是由 qemu 提供的，因此 BIOS 显然具有完全正确的例程来完成这项工作。

如果您可以访问虚拟机的命令提示符，请尝试以下命令：

dmesg | grep -e piix -e ahci -e " sd"

它应该显示与磁盘检测相关的任何消息：如果没有显示任何内容，则未检测到您的（虚拟）存储控制器，这使得无法检测虚拟磁盘。

要修复它，您可能必须访问常规系统中的磁盘映像：（如果/dev/loop0系统已在使用该磁盘映像，请改用免费循环设备）

losetup -P /dev/loop0 srv.sda

然后安装/dev/loop0p1到常规系统中合适的临时位置：

mkdir /mnt/opensuse
mount /dev/loop0p1 /mnt/opensuse

将必要的虚拟文件系统和 chroot 添加到磁盘映像的文件系统中，类似于从实时 Linux 介质引导物理系统时可能执行的操作：

mount --rbind /dev /mnt/opensuse/dev
mount --bind /proc /mnt/opensuse/proc
mount --bind /sys /mnt/opensuse/sys
chroot /mnt/opensuse

现在您应该能够在磁盘映像中重新创建 initrd/initramfs 文件。您没有在映像上指定 OpenSUSE 系统的版本，但经典命令可能是要使用的工具 - 或者它实际上可能是新版本可能使用的mkinitrd任何新工具（也许？）的兼容性别名。dracut

无论使用哪个工具在该版本的 OpenSUSE 中创建 initrd 文件，该工具很可能有一个选项来强制将特定内核模块包含在 initrd 中。阅读该工具的手册页以找到该选项，并使用它创建一个ata_piix包含该模块的新 initrd。（为了安全起见，请先将原始 initrd 文件移到一边。）

一旦您initrd在/boot映像的正确位置成功创建了一个新文件，就exit可以脱离 chroot 环境，umount执行之前执行的所有安装操作，并使用losetup -d /dev/loop0.现在您可以尝试再次启动映像，希望能够成功。

Question 2

通过重新创建 initrd 文件mkinitrd是正确的做法，只是应该在尽可能接近最终目标操作系统将使用的系统上完成。这是因为mkinitrd它在内核和系统上执行了大量的自动检测跑步从，特别是关于可供 initrd 文件使用的内核模块。您已经从主机操作系统重新创建了 initrd 文件，这显然与您的旧机器有很大不同，因此mkinitrd构建了一个不完整/不一致的 initrd。

在这些情况下，最好的方法通常是从原始分布的安装 CD/DVD/ISO，因为这些通常有一个“救援模式”，在这些情况下可以派上用场，从那里重新创建 initrd 文件。在你的情况下，目标操作系统似乎是 openSuSE 11.3，所以你可以获取其 ISOqemu，使用您希望目标操作系统调整到的任何虚拟系统（-hda或者-device ahci甚至是一些 SCSI/SAS，如果您愿意的话）启动它，选择“救援系统”选项，该选项可从该系统的第一个启动菜单中找到ISO，登录root并从那里运行：

~# mount /dev/sda1 /mnt
~# cd /mnt
/mnt# mount --rbind /dev dev && mount --make-rslave dev
/mnt# mount -t proc proc proc
/mnt# mount -t sysfs sysfs sys
/mnt# chroot .
<chrooted># mkinitrd
...
<chrooted># exit
/mnt# umount dev/pts dev/shm dev proc sys
/mnt# cd ..
/# umount mnt

重新创建 initrd 文件。

使用在真实目标系统上运行的真实原始内核（来自 openSuSE 11.3 的内核）启动后qemu，一个没有任何选项的简单内核mkinitrd应该可以正常工作。

当然，在上述操作之后，您将使用相同的虚拟系统但没有 ISO 映像poweroff重新运行。qemu

就像您尝试过的那样，完全有可能从完全不同的操作系统重新创建 initrd 文件，但随后需要准确地知道全部这必需的驱动程序，以便覆盖 . 执行的（不可避免的）不完整/不一致的自动检测mkinitrd。

在您的情况下，我发现您重新创建的 initrd 文件缺少提供磁盘设备sd_mod实际上所需的驱动程序。/dev/sd*它没有被复制可能是因为你的主持人操作系统（您在其上重新创建 initrd 文件）没有该驱动程序作为sd_mod.ko可加载模块，而是将其编译到内核映像本身中。这是很有可能的，因为该模块现在已经成为默认模块，而 10 年前根本不是默认模块，就像它的 IDE 对应模块 ( ide-disk.ko) 直到大约 15 年前才成为默认模块（即编译）一样，而现在它常常被完全忽略。

因此，您可能只需重复在主机操作系统上执行的相同操作，同时还指定sd_mod以及ata_piix，并且您可能已准备就绪。然而，在这种情况下，例如，如果原始安装 CD/DVD/ISO 不可用，更安全的替代方案是mkinitrd -A从主机操作系统上的 chroot 环境内部运行，因为该参数指示mkinitrd简单地包含所有可能的驱动程序。当然，这需要 initrd 文件所在的文件系统有更多的磁盘空间，但是一旦启动到目标操作系统的磁盘，您最终可以使用简单的（即无参数）重新创建 initrd，mkinitrd它会重建精简的 initrd 文件对于新的硬件系统。

Answer