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