我的理解是MBR是512位元組。這前 440 字節（給或者拿A很少 位元組，取決於實作）包含引導程式/引導程式碼區域。其餘位元組包含有關分區表的資訊。
如果我將磁碟的 MBR 清除...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
然後，使用fdisk將分區表寫入/dev/sdX...
# Create a 2GiB partition starting at 2048 (default).
fdisk /dev/sdX
...
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier ...
...
(fdisk) n
(fdisk) p
(fdisk) 1
(fdisk) 2048
(fdisk) +2G
(fdisk) w
然後讀回前 440 個位元組......
dd if=/dev/sdX bs=1 count=440
第一個440位元組仍然全為零。fdisk沒有碰它們，根據我上面發布的鏈接，這是有道理的。fdisk正在寫入分區訊息，因此它應該/不需要觸及第一個440.
接下來的6位元組非零。我假設這些位元組是現代標準 MBR 的磁碟簽名。
$ dd if=/dev/sdX bs=1 count=6 skip=440 | hexdump -e '4/1 "%02x " "\n"'
9a 29 97 e7
到目前為止，根據我對 MBR 佈局方式的理解，這是有意義的。這些第一個440位元組被忽略，fdisk因為它們是引導程式的網域，並且fdisk只與分割表有關。
然而，parted這讓我陷入了困境。
如果我再次將同一磁碟的 MBR 清除...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
然後，使用parted建立一個磁碟標籤（這fdisk似乎是上面自動為我做的）...
parted /dev/sdX mklabel msdos
然後讀回第一個440位元組......
$ dd if=/dev/sdX bs=1 count=440 | hexdump -e '16/1 "%02x " "\n"'
fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00
00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75
f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b
4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
有非零位元組！根據我目前對 MBR 應該如何佈局以及 GNU 的劃分的理解，這似乎沒有意義應該完成。
GNU Parted 是用於建立和操作分區表的程式。
為什麼要parted寫入第一個位元組到資料440？這些位元組不是用於引導程式嗎？分開不應該像以前那樣留下這些位元組嗎fdisk？
答案1
看來我是不是這僅有的一對一注意這種行為。對於某些arm磁碟上有引導程式可能會導致問題的環境來說，這似乎尤其是一個問題。
問題在於，parted 本身（並且默默地）將程式碼放在那裡，因此嵌入式系統認為存在有效的引導程式程式碼並愉快地掛起。
...和...
是否有任何選項可以分開以避免添加此程式碼（並且行為類似於 fdisk）？
看來這種行為parted是故意的。正如郵件連結上的用戶所parted詢問的：
問題是parted從MBR的最開始產生以下程式碼：
…
這段程式碼的目的是什麼？為什麼它被放在那裡？
答案似乎是：
這是通常用於引導 BIOS 系統的 MBR 開機程式碼。如果它在非 x86 系統上引起問題，您應該將其清除（或在分割區後編寫系統引導程式）。
似乎是mklabel為了將通用引導程式寫入磁碟而設計的。至少，當msdos使用 的標籤時。我認為這是有道理的，但是從fdisk和來看syslinux，分區管理器修改引導程式磁區似乎有點不尋常。
它似乎喜歡parted應該不是如果存在非零數據，則覆蓋這些磁區。
不，唯一不會寫入的情況是已經存在某些內容（例如，不是 0x00）。因此，如果您可以讓 SDK 首先編寫它的引導程序，然後對其進行分區，parted 將使其保持不變。
然而，那就是不是我所看到的行為。如果我從 寫入垃圾/dev/urandom，然後運行parted mklabel，我的非零資料肯定會被破壞。
如果我從以下位置組裝mbr.s文件libparted分開的回購協議，我可以看到這些位元組來自哪裡。
$ as86 -b /dev/stdout mbr.s | hexdump -e '16/1 "%02x " "\n"'
fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00
00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75
f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b
4c 02 cd 13 ea 00 7c 00 00 eb fe
那是確切地parted似乎在我的磁碟上產生的位元組序列。