Meu entendimento é que um MBR tem 512 bytes. Oprimeiros 440 bytes(daroupegaraalguns bytes, dependendo da implementação) contêm a área de código do carregador de boot/bootstrap. Os bytes restantes contêm informações sobre a tabela de partição.
Se eu zerar o MBR de um disco...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
Em seguida, use fdiskpara escrever uma tabela de partição em /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
E então leia os primeiros 440 bytes ...
dd if=/dev/sdX bs=1 count=440
Os primeiros 440bytes ainda são todos zero. fdisknão toquei neles, o que faz sentido com base nos links que postei acima. fdiskestá gravando informações de partição, portanto, não deveria/precisaria tocar no primeiro arquivo 440.
Os próximos 6bytes são diferentes de zero. Estou assumindo que esses bytes fazem parte doassinatura de disco de um MBR padrão moderno.
$ dd if=/dev/sdX bs=1 count=6 skip=440 | hexdump -e '4/1 "%02x " "\n"'
9a 29 97 e7
Até agora, isso faz sentido com a minha compreensão de como o MBR é definido. Esses primeiros 440bytes são ignorados fdiskporque são o domínio do bootloader e fdiskse preocupam apenas com tabelas de partição.
No entanto, partedestá me deixando confuso.
Se eu zerar o MBR desse mesmo disco novamente...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
Em seguida, use o parted para criar um rótulo de disco (o que fdiskpareceu acontecer automaticamente para mim acima) ...
parted /dev/sdX mklabel msdos
E então leia os primeiros 440bytes ...
$ 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
Existem bytes diferentes de zero!Isso não parece fazer sentido com o meu entendimento atual de como o MBR deve ser organizado e o que o GNU parte édeveria realizar.
GNU Parted é um programa para criar e manipular tabelas de partição.
Por que está partedgravando dados nesses primeiros 440bytes? Esses bytes não são destinados a um bootloader? O parted não deveria deixar esses bytes em paz como fdiskfez?
Responder1
Parece que estounãooapenasum paraperceberesse comportamento. Parece ser um problema especialmente para alguns armambientes onde ter um bootloader no disco pode causar problemas.
O problema é que o próprio parted (e silenciosamente) coloca o código lá e, portanto, o sistema embarcado pensa que existe um código de bootloader válido e trava felizmente.
...e...
Existe alguma opção de parted para evitar adicionar este código (e se comportar como fdisk)?
Parece que esse comportamento partedéintencional. Como um usuário na partedmailing list pergunta:
O problema é que o parted está gerando o seguinte código desde o início do MBR:
...
Qual é o propósito deste código? Por que foi colocado lá?
E a resposta parece ser:
Esse é o código de inicialização MBR normalmente usado para inicializar um sistema BIOS. Se causar problemas em um sistema não x86, você deve zerá-lo (ou gravar o gerenciador de inicialização do sistema após o particionamento).
Parece que mklabelfoi projetado para gravar um gerenciador de inicialização genérico no disco. Pelo menos, quando um rótulo de msdosestá sendo usado. EUsuponhaisso faz sentido, mas vindo de fdiske syslinux, parece um pouco incomum para um gerenciador de partição modificar setores do bootloader.
Istoparececomo parteddeverianãosubstituir esses setores se dados diferentes de zero estiverem presentes.
Não, a única vez que não será escrito é se já houver algo lá (por exemplo, não 0x00). Então, se você conseguir que o SDK escreva seu bootloader primeiro e depois particione-o, o parted o deixará intacto.
No entanto, isso énãoo comportamento que estou vendo. Se eu escrever lixo de /dev/urandome executar parted mklabel, meus dados diferentes de zero serão definitivamente destruídos.
Se eu montar o mbr.sarquivo a libpartedpartir dorepositório separado, posso ver de onde vêm esses bytes.
$ 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
Aquilo éexatamentea sequência de bytes que partedparece gerar no meu disco.