Насколько я понимаю, MBR — это 512 байт.первые 440 байт(даватьилибратьанемного байты, в зависимости от реализации) содержат область кода загрузчика/bootstrap. Остальные байты содержат информацию о таблице разделов.
Если я обнулю 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 parted.предполагается достичь.
GNU Parted — программа для создания и управления таблицами разделов.
Почему partedданные записываются в эти первые 440байты? Разве эти байты не предназначены для загрузчика? Разве parted не должен оставить эти байты в покое, как fdiskсделал?
решение1
Кажется, янет the толькоодин куведомлениетакое поведение. Похоже, это особенно актуально для некоторых 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как мне кажется, генерируется на моем диске.