Tengo entendido que un MBR tiene 512 bytes. Elprimeros 440 bytes(darollevarapocos bytes, dependiendo de la implementación) contienen el área del código de arranque/cargador de arranque. Los bytes restantes contienen información sobre la tabla de particiones.
Si pongo a cero el MBR de un disco...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
Luego, use fdiskpara escribir una tabla de particiones en /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
Y luego vuelva a leer los primeros 440 bytes...
dd if=/dev/sdX bs=1 count=440
Los primeros 440bytes siguen siendo todos cero. fdiskno los toqué, lo cual tiene sentido según los enlaces que publiqué arriba. fdiskestá escribiendo información de la partición, por lo que no debería/no sería necesario tocar la primera 440.
Los siguientes 6bytes son distintos de cero. Supongo que estos bytes son parte delfirma de disco de un MBR estándar moderno.
$ dd if=/dev/sdX bs=1 count=6 skip=440 | hexdump -e '4/1 "%02x " "\n"'
9a 29 97 e7
Hasta ahora, según mi comprensión de cómo se presenta el MBR, eso tiene sentido. Esos primeros 440bytes se ignoran fdiskporque son el dominio del gestor de arranque y fdisksolo se ocupan de las tablas de particiones.
Sin embargo, partedme está dejando perplejo.
Si vuelvo a poner a cero el MBR de ese mismo disco...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
Luego, use parted para crear una etiqueta de disco (que fdiskpareció funcionar automáticamente para mí arriba)...
parted /dev/sdX mklabel msdos
Y luego vuelva a leer los primeros 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
¡Hay bytes distintos de cero!Eso no parece tener sentido con mi comprensión actual de cómo se debe distribuir el MBR y de qué se separó GNU.se supone que debe lograr.
GNU Parted es un programa para crear y manipular tablas de particiones.
¿Por qué se partedescriben datos en esos primeros 440bytes? ¿No están esos bytes destinados a un gestor de arranque? ¿No debería separarse dejar esos bytes en paz como fdisklo hizo?
Respuesta1
parece que lo soynoelsoloUno paraavisoeste comportamiento. Parece ser un problema especialmente en algunos armentornos donde tener un gestor de arranque en el disco puede causar problemas.
El problema es que se separó (y en silencio) coloca el código allí y, por lo tanto, el sistema integrado piensa que hay un código de gestor de arranque válido y felizmente se cuelga.
...y...
¿Existe alguna opción para separarse para evitar agregar este código (y comportarse como fdisk)?
Parece que este comportamiento partedesintencional. Como partedpregunta un usuario de la lista de correo:
El problema es que parted genera el siguiente código desde el principio del MBR:
...
¿Cuál es el propósito de este código? ¿Por qué se ha puesto ahí?
Y la respuesta parece ser:
Ese es el código de inicio MBR que normalmente se usa para iniciar un sistema BIOS. Si causa problemas en un sistema que no sea x86, debe ponerlo a cero (o escribir el gestor de arranque del sistema después de la partición).
Parece que mklabelestá diseñado para escribir un gestor de arranque genérico en el disco. Al menos, cuando msdosse utiliza una etiqueta de. Isuponereso tiene sentido, pero viniendo de fdisky syslinux, parece un poco inusual que un administrador de particiones modifique los sectores del gestor de arranque.
Élparececomo parteddeberíanosobrescribirá esos sectores si hay datos distintos de cero.
No, la única vez que no lo escribirá es si ya hay algo allí (por ejemplo, no 0x00). Entonces, si puede hacer que el SDK escriba su gestor de arranque primero y luego particionarlo, la partición lo dejará intacto.
Sin embargo, eso esnoel comportamiento que estoy viendo. Si escribo basura desde /dev/urandomy luego ejecuto parted mklabel, mis datos distintos de cero definitivamente están siendo golpeados.
Si armo el mbr.sarchivo libparteddesde elrepositorio dividido, puedo ver de dónde vienen esos 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
Eso esexactamentela secuencia de bytes que partedparece generarse en mi disco.