Por que o GNU separou os dados gravados nos primeiros 440 bytes do MBR?

3

Meu entendimento é que um MBR tem 512 bytes. Os primeiros 440 bytes ( ou pegue a poucos bytes , dependendo da implementação, contêm a área de código do boot loader / bootstrap. Os bytes restantes contêm informações sobre a tabela de partições.

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 fdisk para gravar uma tabela de partições 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

Depois, leia os primeiros 440 bytes ...

dd if=/dev/sdX bs=1 count=440

Os primeiros 440 bytes ainda são todos zero. fdisk não tocou neles, o que faz sentido com base nos links que postei acima. fdisk está escrevendo informações de partição, portanto, ele deve / não precisa tocar no primeiro 440 .

Os próximos 6 bytes são diferentes de zero. Estou assumindo que esses bytes fazem parte da assinatura de disco de um padrão MBR 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 é apresentado. Aqueles primeiros 440 bytes são ignorados por fdisk porque são o domínio do gerenciador de inicialização e fdisk está preocupado apenas com as tabelas de partição.

No entanto, parted está me jogando por um loop.

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 (que fdisk pareceu fazer automaticamente para mim acima) ...

parted /dev/sdX mklabel msdos

Depois, leia o primeiro 440 bytes ...

$ 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 apresentado e o que o GNU separou como objetivo de realizar .

GNU Parted is a program for creating and manipulating partition tables.

Por que parted está gravando dados nesses primeiros 440 bytes? Esses bytes não são destinados a um gerenciador de inicialização? Não deveria separar os bytes como fdisk ?

    
por Will Haley 03.04.2018 / 09:16

1 resposta

0

Parece que eu sou não do only um para observe esse comportamento. Parece ser especialmente um problema para alguns arm ambientes em que ter um bootloader no disco pode causar problemas.

The problem is that parted itself (and silently) puts the code there and hence the embedded system thinks that there is a valid bootloader code and happily hangs.

... e ...

Is there any option to parted to avoid adding this code (and behave like fdisk)?

Parece que esse comportamento de parted é intencional . Como um usuário no log de correspondência parted pergunta:

The problem is that parted is generating following code from the very beginning of the MBR:

...

What is the purpose of this code? Why is has been put there?

E a resposta parece ser:

That's the MBR boot code normally used to boot a BIOS system. If it causes problems on a non-x86 system you should zero it out (or write the system bootloader after partitioning).

Parece que mklabel foi projetado para gravar um gerenciador de inicialização genérico no disco. Pelo menos, quando um rótulo de msdos está sendo usado. Suponho que isso faz sentido, mas vindo de fdisk e syslinux , parece um pouco incomum para um gerenciador de partição modificar os setores do carregador de inicialização.

parece como parted não substitua esses setores se houver dados diferentes de zero.

No, the only time it won't write it is if there is something already there (eg. not 0x00). So if you could get the SDK to write it's bootloader first, then partition it, parted will leave it untouched.

No entanto, isso não é o comportamento que estou vendo. Se eu escrever lixo a partir de /dev/urandom , então execute parted mklabel , meus dados diferentes de zero estão definitivamente sendo corrompidos.

Se eu reunir o arquivo mbr.s em libparted do repo parcial , posso ver onde esses bytes estão vindo.

$ 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

Isso é exatamente a sequência de bytes que parted parece gerar no meu disco.

    
por 05.04.2018 / 05:48

Tags