![这些重叠分区的用途是什么?](https://linux22.com/image/1622567/%E8%BF%99%E4%BA%9B%E9%87%8D%E5%8F%A0%E5%88%86%E5%8C%BA%E7%9A%84%E7%94%A8%E9%80%94%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%9F.png)
我想安装抛物线在我的其中一台机器上,因此我下载了 .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 类型的整个分区。
现在这有点道理了,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 是必要的/有益的……?