initramfs 中的 squashfs 分区的可预测分区名称

initramfs 中的 squashfs 分区的可预测分区名称

长话短说:如何使用可预测的分区名称从 initramfs 启动 squashfs 分区?/dev/sda2不起作用,因为设备名称会随机重新排序,有时会从错误的分区启动。


我们使用 Gentoo 的自定义安装,如下所示:

/dev/sda1: /boot   ext4 (unencrypted)
/dev/sda2: /       squashfs (unencrypted)
/dev/sda3: /home   ext4 (dm-crypt)
/dev/sda4: -       swap

我们制作了一个自定义的 initramfs 脚本,用于安装根分区和其上的 tmpfs 作为覆盖文件系统。我们用了本指南它看起来像这样:

#!/bin/busybox sh
mount -t proc none /proc
mount -t sysfs none /sys

# Mount the root filesystem.
mount -t squashfs -o ro /dev/sda2 /mnt/overlay
# (some stuff to set up the overlay with tmpfs is done here)

# Clean up. 
umount /proc
umount /sys

# Boot the real thing.
exec switch_root /mnt/overlay /sbin/init

只要这是系统上唯一的磁盘,它就会正常启动并且一切正常,因为它/dev/sda2始终是只有一个磁盘的系统中的根分区。

我们正在开发自动更新系统,因为此自定义安装将运送到其他城市,理想情况下,我们的客户应该能够通过简单地插入 USB 记忆棒并等待更新完成来更新他们的系统。通过互联网进行更新不是一种选择。保证数据安全是重中之重,我们相信我们选择的分区方案足够安全,足以满足我们的需求,尽管我们愿意接受新想法,如果这意味着解决我们的问题:

U 盘更新系统是原始 Gentoo 安装的副本,并使用完全相同的分区方案。然而,USB 记忆棒中的 initramfs 脚本会变得混乱,并且通常会选择原始安装的根目录,而不是 USB 更新程序的根目录。显然,更新程序(位于 U 盘根目录下)永远不会像这样运行。

我们尝试将/dev/sda2USB 记忆棒的 initramfs 脚本替换为

  1. /dev/disk/by-id/usb*part2,它已经在 GRUB2 菜单中工作,但在 initramfs 脚本中不起作用,因为/dev/disk此时不存在(顺便问一下,为什么它存在于 GRUB 中?)
  2. $(findfs PARTUUID="partid-of-usb-squashfs-root"),没用
  3. $(findfs UUID="x"),如果squashfs分区有文件系统UUID,这将起作用(这适用于ext4和其他文件系统)

该指南建议在初始化时使用 devtmpfs 或 mdev 进行填充/dev,但我们不知道这有什么帮助,因为这/dev/disk似乎是 udev 的工作,而devtmpfs从 initramfs 脚本启动似乎没有帮助。

当根分区没有文件系统 UUID 时,如何在 initramfs 脚本中获取可预测/持久的分区名称?

更改分区方案有点困难,而且我们不希望普通 Windows 用户看到我们的 squashfs 根目录或 /home 分区,但如果有其他方法可以让我们可靠地启动,我们会尝试做一些事情每次都来自同一个分区,例如 LVM 或其他我们没有想到的东西。

答案1

为此无需依赖任何特殊工具。

知道squashfs分区在分区方案中总是第二个分区就足够了:只需设置pendrive第一个分区的UUID,对结果进行使用$(findfs UUID=first-pendrive-partition)和执行即可。sed s/1/2/

现在系统总是检测到正确的分区。

答案2

LVM 是这种情况下的候选者,但反而增加了引导加载程序/initramfs 的复杂性。

您能否保证只有一个squashfs文件系统作为块设备存在?如果是这样,那么您可以用来findfs TYPE=squashfs查找正确的根文件系统。

但是,您注意到您的 USB 密钥几乎相同,因此也包含squashfs文件系统。因此,您需要开始寻找放置跟踪信息的替代位置。你的/boot卷看起来是一个不错的候选者;在 USB 密钥上,它可以有一些将其标记为可移动设备的内容;在硬盘驱动器上,它可以有一些东西将其标记为真正的安装。

相关内容