“无法挂载 API 文件系统”。在复制的驱动器上更新了分区 UUID

“无法挂载 API 文件系统”。在复制的驱动器上更新了分区 UUID

因此,我直接克隆了我的主要 Linux 安装的分区布局。即 Fedora 38,使用以下命令。

sgdisk --backup=table /dev/sda
sgdisk --load-backup=table /dev/sdb

我更新了 /etc 目录和 /boot 和 /boot/efi 目录中的 UUID 和对它们的所有引用。使用 gparted 更新各个分区的 UUID 后,其中包含 grub 配置和挂载表。

我曾经注意到,在我运行的至少一个版本的内核中,我很难安装具有相似 UUID 的多个卷,并且在处理 fstab 时,它会导致在启动时加载错误的分区。

当我从 BIOS 中选择启动设备并指定 SATA 到 USB 驱动器时,它就开始启动。

然而,无论是安装主硬盘还是外部 SATA 至 USB 驱动器,启动都会在“达到目标基本系统”时冻结。

当我断开驱动器时,它工作正常,所有分区都可以与主操作系统一起安装,并且除了前面提到的更新的参考文件之外的所有内容都是相同的。

我仔细检查了文件是否损坏或更改(除了必要的更改之外)。最初使用以下命令进行了复制。

tar cf - . | (cd /mnt/dest && tar xvf -) 

为了再次检查所有内容是否相同,我在复制完成后也运行了 rsync,结果发现所有内容都检查完毕。

为了测试我的工作,我使用原始磁盘创建了一个指向驱动器的 vmdk,并尝试通过 virtualbox 启动它。

这次进展进一步如下:

“无法挂载 API 文件系统”。

我必须承认我有点困惑这个问题是什么。

另请注意下列事项。

使用 claude.ai 我找到了一些允许您搜索整个 linux 和开源代码库的网站,并发现这个错误直接来自 System-D。

看起来这是一个非常熟悉的、很久以前的过程,现在一定有人发现了为什么会发生这种情况。

例如。

https://sourcegraph.com/github.com/systemd/systemd@296afa847704a61177b2ceea4dae4f2148cc27d0/-/blob/src/core/main.c

我只是想知道为什么会失败。我已经使用 dd if/of 直接克隆了驱动器,并且能够多次通过带有 usb 3 转 sata 连接器的 virtualbox 运行它们,就像我现在所做的那样,我为 virtualbox 实例和几个核心分配了大量的 RAM,所以我想知道为什么会发生这种情况。

无可否认,并非真正尝试使用附加调试点来自定义构建 system-d。

相关内容