Почему GNU разделил запись данных в первые 440 байтов MBR?

Question

Насколько я понимаю, MBR составляет 512 байт. Первые 440 байт (дают или берут несколько байтов, в зависимости от реализации) содержат область кода загрузчика / загрузчика. Остальные байты содержат информацию о таблице разделов.

Если я обнулю 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 байтов? Разве эти байты не предназначены для загрузчика? Разве parted не должен оставлять эти байты в покое, как это сделал fdisk ?

Answer 1

Казалось бы, я не единственный, кто заметил это поведение. Это , кажется, особенно быть проблемой для некоторых сред arm , где имея начальный загрузчик на диске может вызвать проблемы.

Проблема в том, что parted сам (и молча) помещает туда код, и, следовательно, встроенная система думает, что существует правильный код загрузчика, и благополучно зависает.

...а также...

Есть ли опция parted, чтобы избежать добавления этого кода (и вести себя как fdisk)?

Кажется, что такое поведение при parted является преднамеренным. Как пользователь на parted почтовой рассылке спрашивает:

Проблема в том, что parted генерирует следующий код с самого начала MBR:

...

Какова цель этого кода? Почему это было положено там?

И ответ, кажется, таков:

Это загрузочный код MBR, обычно используемый для загрузки системы BIOS. Если это вызывает проблемы в системах, отличных от 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 похоже, генерирует на моем диске.