☰

这些重叠分区的用途是什么？

tag-icon • tag-icon linux partitioning mount usb-flash-drive iso-image
这些重叠分区的用途是什么？

我想安装抛物线在我的其中一台机器上，因此我下载了 .iso，检查了签名和哈希值，然后将映像刷入 USB 拇指驱动器，如下所示：

dd if=parabola-dual-openrc-cli-2020.01.18-netinstall.iso of=/dev/sde oflag=direct bs=1M status=progress

这似乎按预期工作，因为我现在可以从这个驱动器启动，但我发现了一些奇怪的事情。磁盘管理现在报告驱动器上有两个分区，第一个分区显然是未知类型，第二个分区嵌套在其中：

$ fdisk -l /dev/sde | grep -i dev
Disk /dev/sde: 7,5 GiB, 8086618112 bytes, 15794176 sectors
Device     Boot Start     End Sectors  Size Id Type
/dev/sde1  *        0 1796095 1796096  877M  0 Empty
/dev/sde2         172  131243  131072   64M ef EFI (FAT-12/16/32)

分开甚至没有“看到” sde1，它只显示第二个分区。

$ parted /dev/sde -s print | tail -n +7
Number  Start   End     Size    Type     File system  Flags
 2      88,1kB  67,2MB  67,1MB  primary  fat16        esp

分区更进一步，仅将块设备显示为 iso9660 类型的整个分区。

GParted 将 /dev/sde 显示为一个分区，其文件系统为 iso9660，标签为 PARA_202001

现在这有点道理了，ISO9960显然是定义数据如何在光盘上布局的标准，因此当将 iso 映像 1:1 写入驱动器时，这似乎是一个合理的结果。

我确实可以安装这两个驱动器并查看其所有内容。只有sde1驱动器以只读方式安装，尽管光盘通常始终是只读的。

$ cd /mnt; sudo mkdir new; sudo mkdir new2
$ sudo mount /dev/sde1 new
mount: /mnt/new: WARNING: device write-protected, mounted read-only.
$ sudo mount /dev/sde2 new2

似乎大多数文件sde2（仅包含目录EFI）也位于sde1同一位置：

$ paste <(tree /mnt/new2/EFI) <(tree /mnt/new/EFI) | column -s $'\t' -t
/mnt/new2/EFI                        /mnt/new/EFI
├── boot                             ├── boot
│   ├── bootx64.efi                  │   ├── bootx64.efi
│   ├── entries                      │   ├── entries
│   │   ├── parabolaiso-x86_64.conf  │   │   ├── parabolaiso-x86_64.conf
│   │   └── uefi-shell-x86_64.conf   │   │   └── uefi-shell-x86_64.conf
│   ├── HashTool.efi                 │   ├── HashTool.efi
│   ├── loader.efi                   │   ├── loader.efi
│   └── refind.conf                  │   └── refind.conf
├── parabolaiso                      ├── parabolaiso
│   ├── parabolaiso.img              │   └── efiboot.img
│   └── vmlinuz.efi                  ├── shellx64_v1.efi
├── shellx64_v1.efi                  └── shellx64_v2.efi
└── shellx64_v2.efi                  3 directories, 9 files
3 directories, 10 files

更深入地讲，由于这些分区现在已经安装好了，我看了一下检测到了哪些选项：

$ cat /proc/mounts | grep /dev/sde
/dev/sde1 /mnt/new iso9660 ro,relatime,nojoliet,check=s,map=n,blocksize=2048 0 0
/dev/sde2 /mnt/new2 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0

因此，它sde2不仅仅是一些似乎专门针对 EFI 进行优化的 FAT，而且还具有心室颤动扩展以允许更长的文件名。

这到底是怎么回事？刻录的 ISO 图像总是这个样子吗？还是 Parabola 正在做一些奇怪而特别的事情？

这是否可能与该映像可在 i686 和 x86_64 架构上启动有关？

答案1

这到底是怎么回事？刻录的 ISO 图像总是这个样子吗？还是 Parabola 正在做一些奇怪而特别的事情？

“刻录的 ISO 映像”不会改变其外观；磁盘映像的全部目的是它是磁盘的 1:1 表示，并将按原样写入。因此，这也是原始 .iso 文件的外观。

原始 ISO 文件看起来像这样，因为它已专门准备作为 CD/DVD 启动（ISO 映像的原始目标）和HDD/USB 磁盘。这会导致整个混乱，因为：

  • EFI 可能希望 USB 磁盘具有有效的分区表，但 CD 和 DVD 却没有不根本没有典型的 HDD 分区表 - 扇区 0 处既没有 MBR，扇区 1 处也没有 GPT。整个磁盘是一个 ISO 9660 文件系统（或 UDF 或两者），扇区 16 处有一个“卷描述符集”。

  • BIOS 要求 USB 磁盘具有引导扇区，但 CD 不使用引导扇区。相反，它们有一个埃尔托里托“引导目录”具有针对不同平台的多个条目，每个条目可能指向具有自己的引导扇区的不同“磁盘映像”。

    换句话说，ISO 9660 结构可能嵌入了整个微小的 FDD/HDD 映像，以便 BIOS 可以启动它并假装它是从 FDD 启动的；这也扩展到基于 EFI 的启动，其中启动目录可能有一个“EFI (x86_64)”条目，它指向包含 EFI 系统分区的 HDD 映像。

    （如果您尝试使用 7-zip 打开 ISO 映像，这些将显示在名为“[BOOT]”的虚假目录中。）

因此，如果您只是获取标准 ISO 9660 映像并将其写入 USB 记忆棒，它可能根本无法启动，因为 BIOS 启动扇区或 EFI 分区表位于某个深处，而不仅仅是从扇区 0 开始。

但实际上，ISO 9660镜像的最初几个扇区是“未使用的”（因为一些早期平台确实在其中放置了一个引导扇区），因此有一个名为的工具isohybrid可以制作一个BIOS引导扇区和一个EFI分区表，它们都指向ISO 9660结构内的El Torito引导镜像，一旦完成，镜像就有根据您开始查找的位置，可以找到两到三种不同的数据结构。

  • 如果你将映像刻录到 CD，则固件首先会查找 ISO 9660“卷描述符”第 16 区，它确实会发现整个磁盘是一个 ISO 9660 文件系统（它有一个 El Torito 引导记录，其中包含嵌入式 FAT32 文件系统）。

  • 但如果你有一个 USB 记忆棒，那么固件可能会首先寻找 GPT 分区表，区域 1，它确实会发现它是一个 GPT 分区的磁盘，并且在一个稍微奇怪的位置有一个“EFI 系统分区”。

    （因此，如果您挂载该分区并更新它，从技术上讲，您就是在编辑通常只读的 ISO 9660 文件系统的内部结构。）

    但是，如果 GPT 仅引用该单个分区，那么其余的 ISO 9660 结构将显示为“可用空间”，并且如果用户在同一磁盘上创建自己的分区并认为有足够的空间，则这些结构有被损坏的风险。

    为了避免这种情况，isohybrid 创建了包含整个 ISO 9660 文件系统的第二个分区 - 它自然与从同一个 ISO 9660 文件系统中“剪切”出来的 EFI 分区重叠。

  • 更有趣的是，如果固件或软件首先寻找膜生物反应器分区表位于0 区，它也会找到一个 - 其条目与 GPT 分区条目完全镜像。

    除了 isohybrid 使用分区类型00来指定“空”分区之外，libparted 似乎不太理解这一点并认为整个分区槽都是空的。

UEFI 规范为所有可移动媒体定义了一个特定的检查顺序：1) 查找 GPT 分区；2) 查找 El Torito；3) 查找 MBR 分区。但这不适用于分区工具 - 在您的例子中，fdisk 首先找到 MBR，等等。

更为复杂的是，内核执行的分区发现与 fdisk、gdisk、parted 或 GParted 执行的分区发现完全不同。尽管 fdisk说第一个 MBR 分区是“/dev/sda1”，这与内核认为的 /dev/sda1 实际上是无关的。

所有这些工具都有自己的代码来独立于内核解析分区表。它们只是假设磁盘的数据结构是明智的这样，不同的程序会对 /dev/sda1 得出相同的结论，但正如您所见，“isohybrid”ISO 映像与此相反。

所以总而言之，奇怪的是试图使 CD 映像可用和/或可启动为 HDD 映像，这就像您尝试制作 .mp3 一样，这也是一个有效的 .zip 文件。

这一切都恰好起作用，因为所有重要的数据结构都相互不冲突：

  • 当通过扇区 16 检测磁盘为 ISO 9660 时，代码会忽略扇区 0-15 中的内容，因为这是 ISO 9660“未使用”区域的一部分。

  • 当通过扇区 0 将磁盘检测为 MBR 时，代码会忽略扇区 16 中的内容，因为 MBR 没有延伸那么远。

  • 当通过扇区 1 检测磁盘为 GPT 时，代码会忽略扇区 16 中的内容，因为 GPT（在扇区 63 结束）也没有延伸那么远……？

    最后一部分之所以有效，是因为扇区大小不同（CD 的扇区大小为 2048 字节，而 USB 记忆棒的扇区大小为 512 字节），因此卷描述符集实际上并不位于扇区 16，而是位于扇区 64，并且 GPT 实际上并没有延伸那么远。

  • 扇区大小也应该可以解释为什么在将磁盘写入 USB 驱动器后，UEFI 不会简单地将磁盘检测为 ISO 9660，尽管我之前提到过，这是所有类型介质的规范——固件将查看“扇区 16”，但因为现在是以 512 字节为单位的扇区 16，而不是以 2048 字节为单位，所以它将远离 ISO 9660 VDS；它只会找到 GPT 中间的空白区域。

    反之亦然，当图像位于 CD 上时，其 GPT 不再从“扇区 1”开始 - 它现在位于扇区 0 的中间，因此无法在 CD 上检测到。

    最后，0 扇区的 MBR 仍然在 0 扇区，因此会被检测到……但由于其分区引用也是以扇区为单位，因此它们将完全不匹配。这就是为什么 UEFI 优先考虑 ISO9660 而不是 MBR。

因此，sde2 不仅仅是一些似乎专门针对 EFI 进行优化的 FAT，而且它还具有 VFAT 扩展以允许更长的文件名。

这些都是完全相同的东西；UEFI 规范将“EFI 文件系统”定义为基于带有 LFN 扩展的 FAT12/16/32。（“vfat”是 Linux 调用 Windows 95 引入的带有 LFN 的 FAT 的方式。）

  • EFI 包括使用 FAT32 作为系统分区，以及使用 FAT12 或 FAT16 作为可移动媒体。FAT32 系统分区由 OSType 值标识，不同于用于标识以前版本的 FAT 的值。这种独特的分区类型将 EFI 定义的文件系统与普通的 FAT 文件系统区分开来。EFI 支持的文件系统包括对长文件名的支持。

    （UEFI 规范第 13.3 节）

答案2

由于我没有深入的理解，这并不能完全回答整个问题，但至少为未来用谷歌搜索的读者提供了一些链接。

这不是 Parabola 独有的，我在 Debian（live debian 12）镜像中也看到了同样的情况。帖子在 Debian 论坛中证实了我的观察，即 gparted 和 gdisk 拒绝干预混合 ISO“文件系统”的那些重叠分区，但 fdisk 可以在可用空间中创建一个新分区（尽管它会以红色打印警告/警告）。

和维基百科写了关于这个似乎相当古老的混合文件系统布局的文章

[...] 发布适用于 DOS（后来的 Windows）和经典 Mac OS（后来的 macOS）产品的公司可以发布一张包含适用于这两种操作系统的软件的 CD，这些软件在任一系统上都可以本地读取。数据文件甚至可以由两个分区共享，同时将平台特定数据分开。在“真正的”（或“共享的”）混合 HFS 文件系统中，ISO 9660 和 HFS 分区共有的文件仅存储一次，其中 ISO 9660 分区指向 HFS 区域中的文件内容（反之亦然）[...]

显然，EFI 分区的内容在启动时应由主板读取，并且\稍后也应成为树的一部分，他们不想mount在启动后通过加载其他 FS 来执行此操作。我认为，这对于用作实时 CD/USB 是必要的/有益的……？

相关内容