USB 设备上没有引导扇区

Question

该 ISO 映像只能作为（真实或虚拟）CD-ROM 启动；它没有额外的结构来使其也显示为有效的可启动硬盘映像。

在具有 BIOS 的系统上从 USB 驱动器引导通常是通过将 USB 驱动器显示为硬盘来处理的。如果硬盘的第一个块具有有效的主引导记录 (MBR)，则该硬盘将可通过 BIOS 引导。

另一方面，如果 CD-ROM 在其 ISO 9660 文件系统扩展中包含 Eltorito 引导标头，则该 CD-ROM 是可引导的...并且这些扩展通常不位于磁盘的最开头，而是位于由 ISO 确定的位置9660 文件系统结构。

可以制作 .ISO 映像文件还通过在磁盘的最开头添加 MBR 并以与其兼容的方式排列 ISO9660 文件系统的内容，可以将其解析为有效的硬盘映像。但这不是默认设置：尽管大多数现代 Linux ISO 安装映像都是以这种方式准备的，但并非全部都是如此。

这个特定的 ISO 显然不是，因为您可以转储 ISO 映像的前 512 字节并看到它仅包含零：

$ dd if=CentOS-7-i386-Minimal-2009.iso bs=512 count=1 | od -t x1z -A x
1+0 records in
1+0 records out
512 bytes copied, 7.6959e-05 s, 6.7 MB/s
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
000200

ISO 映像的前 512 字节有准备好也可以使用，因为 BIOS 可启动硬盘映像看起来会更加复杂。例子：

$ dd if=/usr/lib/ipxe/ipxe.iso bs=512 count=1 | od -t x1z -A x
1+0 records in
1+0 records out
512 bytes copied, 0.00298604 s, 171 kB/s
000000 33 ed 90 90 90 90 90 90 90 90 90 90 90 90 90 90  >3...............<
000010 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  >................<
000020 33 ed fa 8e d5 bc 00 7c fb fc 66 31 db 66 31 c9  >3......|..f1.f1.<
000030 66 53 66 51 06 57 8e dd 8e c5 52 be 00 7c bf 00  >fSfQ.W....R..|..<
000040 06 b9 00 01 f3 a5 ea 4b 06 00 00 52 b4 41 bb aa  >.......K...R.A..<
000050 55 31 c9 30 f6 f9 cd 13 72 16 81 fb 55 aa 75 10  >U1.0....r...U.u.<
000060 83 e1 01 74 0b 66 c7 06 f3 06 b4 42 eb 15 eb 02  >...t.f.....B....<
000070 31 c9 5a 51 b4 08 cd 13 5b 0f b6 c6 40 50 83 e1  >1.ZQ....[...@P..<
000080 3f 51 f7 e1 53 52 50 bb 00 7c b9 04 00 66 a1 b0  >?Q..SRP..|...f..<
000090 07 e8 44 00 0f 82 80 00 66 40 80 c7 02 e2 f2 66  >[email protected]<
0000a0 81 3e 40 7c fb c0 78 70 75 09 fa bc ec 7b ea 44  >.>@|..xpu....{.D<
0000b0 7c 00 00 e8 83 00 69 73 6f 6c 69 6e 75 78 2e 62  >|.....isolinux.b<
0000c0 69 6e 20 6d 69 73 73 69 6e 67 20 6f 72 20 63 6f  >in missing or co<
0000d0 72 72 75 70 74 2e 0d 0a 66 60 66 31 d2 66 03 06  >rrupt...f`f1.f..<
0000e0 f8 7b 66 13 16 fc 7b 66 52 66 50 06 53 6a 01 6a  >.{f...{fRfP.Sj.j<
0000f0 10 89 e6 66 f7 36 e8 7b c0 e4 06 88 e1 88 c5 92  >...f.6.{........<
000100 f6 36 ee 7b 88 c6 08 e1 41 b8 01 02 8a 16 f2 7b  >.6.{....A......{<
000110 cd 13 8d 64 10 66 61 c3 e8 1e 00 4f 70 65 72 61  >...d.fa....Opera<
000120 74 69 6e 67 20 73 79 73 74 65 6d 20 6c 6f 61 64  >ting system load<
000130 20 65 72 72 6f 72 2e 0d 0a 5e ac b4 0e 8a 3e 62  > error...^....>b<
000140 04 b3 07 cd 10 3c 0a 75 f1 cd 18 f4 eb fd 00 00  >.....<.u........<
000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
0001b0 48 07 00 00 00 00 00 00 c4 7a ef 12 00 00 80 00  >H........z......<
0001c0 01 00 17 3f 20 01 00 00 00 00 00 10 00 00 00 00  >...? ...........<
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa  >..............U.<
000200

第一部分是 MBR 中的引导代码（在本例中，它显然使用 SYSLINUX 系列引导加载程序中的 ISOLINUX，这是有意义的，因为磁盘映像主要部分中的文件系统类型将是 ISO9660），然后是实际的 MBR分区表，最后两个字节包含 0x55 0xaa 签名字节。

为什么 CentOS 发行版构建者在这种特定情况下省略了 ISO 映像准备步骤？只有他们自己可能知道：也许这是一个错误，有人只是忘记将其包含在 32 位最小安装介质的发布过程中。或者也许他们出于某种原因选择这样做。

只是为了完整性：

如果 ISO 映像还需要使用 UEFI 本机引导过程（而不是 BIOS 兼容性支持机制）在 UEFI 固件下进行引导，则将应用另一组要求。映像开头的分区表（MBR 或 GPT）需要至少包含一个用特殊标记标记的 FAT32 分区EFI系统分区类型标识符（MBR 分区为 0xef，GPT 分区为特定分区类型 GUID）。该分区需要将引导加载程序作为专门命名的文件：对于 32 位 x86 架构，这将表示\EFI\BOOT\BOOTIA32.EFI为 Windows 样式的路径名。对于 64 位 x86 架构，UEFI 引导路径名为\EFI\BOOT\BOOTX64.EFI.

实际上，一些 UEFI 固件实现在一定程度上放宽了这些要求。可移动媒体可能如果 UEFI 固件在正确的路径中包含适当命名的引导加载程序文件，则将其视为可由 UEFI 固件引导在该特定 UEFI 固件实现可读的任何文件系统上。所有 UEFI 固件实现都需要将 FAT32 理解为 UEFI 规范的一部分；但不同的实现可以添加其他文件系统类型。例如，Apple 的 UEFI 本身也可以理解 HFS+ 文件系统。

Answer 1