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

378
Will Haley

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

3
Вы пытались загрузить диск, разделенный с помощью Parted? Melebius 6 лет назад 1
Я не пробовал это, пока ты не предложил это. Я получаю черный экран при загрузке с этого диска. Интересно, что я не вижу что-то вроде «Не найдено загрузочного носителя!». Это ошибка, которую я получаю, если загружаюсь с полностью чистого диска. Похоже, что `parted` пишет какой-то квази-правильный код загрузчика, который пытается выполнить BIOS, но этого недостаточно. Will Haley 6 лет назад 1
Я предполагаю, что это ошибка в Parted, лучше всего обсуждаемая на его форумах, которые, похоже, [здесь] (http://gparted-forum.surf4.info/). harrymc 6 лет назад 0

1 ответ на вопрос

0
Will Haley

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