Centos

USB 設備上沒有引導扇區

  • March 11, 2021

從這裡下載了一個最小的 CentOS 32 位 ISO 映像:

http://mirror1.hs-esslingen.de/pub/Mirrors/centos-altarch/7.9.2009/isos/i386/

$ curl -O http://mirror1.hs-esslingen.de/pub/Mirrors/centos-altarch/7.9.2009/isos/i386/CentOS-7-i386-Minimal-2009.iso -C -

要在 USB 驅動器上寫入 ISO 映像:

  • dd在 Linux 上嘗試過的命令
  • 在這裡建議在 Windows 上嘗試 FedoraMediaWriter
  • 嘗試了一個 8GB 的​​ USB 驅動器
  • 嘗試了另一個 2GB USB 驅動器

在所有情況下,從 USB 啟動時,我都會收到此錯誤:

USB 設備上沒有引導扇區

ISO 映像包含:

ISO 映像內容

為什麼 ISO 映像無法啟動?我錯過了什麼嗎?

該 ISO 映像只能作為(真實或虛擬)CD-ROM 引導;它沒有額外的結構使其也顯示為有效的可引導硬碟映像。

在具有 BIOS 的系統上從 USB 驅動器引導通常通過使 USB 驅動器顯示為硬碟來處理。如果硬碟具有有效的主引導記錄 (MBR) 作為其第一個塊,則該硬碟將是 BIOS 可引導的。

另一方面,如果 CD-ROM 在其 ISO 9660 文件系統擴展中包含 Eltorito 引導標頭檔,則它是可引導的……並且這些擴展通常不位於磁碟的最開頭,而是位於由 ISO 確定的位置9660 文件系統結構。

通過在磁碟的最開頭添加 MBR 並以與它兼容的方式排列 ISO9660 文件系統的內容,可以製作一個也可解析為有效硬碟映像的 .ISO 映像文件。*但這不是預設設置:*儘管大多數現代 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

準備好也可用作 BIOS 可引導硬碟映像的 ISO 映像的前 512 字節看起來要復雜一些。例子:

$ 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  >..D.....f@.....f<
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 韌體下使用 UEFI 本機引導過程(而不是 BIOS 兼容性支持機制)可引導,則將應用另一組要求。映像開頭的分區表(MBR 或 GPT)需要包含至少一個 FAT32 分區,該分區標有特殊的EFI 系統分區類型標識符(0xef 用於 MBR 分區,特定分區類型 GUID 用於 GPT 分區)。並且該分區需要將引導載入程序作為一個專門命名的文件:對於 32 位 x86 架構,這將\EFI\BOOT\BOOTIA32.EFI表示為 Windows 樣式的路徑名。對於 64 位 x86 架構,UEFI 引導路徑名將是\EFI\BOOT\BOOTX64.EFI.

在實踐中,一些 UEFI 韌體實現在一定程度上放寬了這些要求。如果可移動媒體在該特定 UEFI 韌體實現可讀的任何文件系統上的正確路徑中包含適當命名的引導載入程序文件,則它**可以被認為是 UEFI 韌體可引導的。所有 UEFI 韌體實現都需要將 FAT32 理解為 UEFI 規範的一部分;但不同的實現可以添加其他文件系統類型。例如,Apple 的 UEFI 也將原生地理解 HFS+ 文件系統。

引用自:https://unix.stackexchange.com/questions/638694