¿Cómo corregir el MBR de sector de 512 bytes en un disco de sector de 4096 bytes?

Las cuestiones relativas al tamaño del sector se están volviendo bastante complejas. Hasta finales de 2009, la gran mayoría de los discos duros usaban sectores de 512 bytes, y eso fue todo. A fines de 2009, los fabricantes de discos comenzaron a introducir el llamado Formato avanzado. (AF), que utilizan sectores de 4096 bytes. Estos primeros discos AF (y, AFAIK, todos los discos AF actuales) presentan una interfaz para la computadora que muestra cada físico de 4096 bytes. sector dividido en ocho lógico de 512 bytes sectores Esta conversión permite que las herramientas más antiguas, incluidas muchas BIOS, que se construyeron con suposiciones de 512 bytes, continúen funcionando. No sé si su disco usa AF o no, pero en cualquier caso, es casi seguro que usa un tamaño de sector lógico de 512 bytes, lo que significa que la interfaz del sistema operativo debería usar sectores de 512 bytes.

Para complicar las cosas, hay ciertos gabinetes de discos USB. Algunos de estos gabinetes hacen lo contrario de lo que hace AF:toman ocho sectores de disco y los agrupan en un nuevo sector de 4096 bytes. No estoy seguro de cuál es el razonamiento detrás de este movimiento, pero una ventaja práctica es que los discos de más de 2 TiB se pueden usar con el antiguo sistema de partición MBR. Una gran desventaja es que un disco particionado en uno de estos gabinetes no se puede usar directamente o en un gabinete que no haga este tipo de traducción. Del mismo modo, un disco preparado sin esta traducción no se puede utilizar cuando se transfiere a dicho recinto. Tenga en cuenta que este problema va mucho más allá del propio MBR; su disco podría identificar que la primera partición comienza en el sector 2048 (512 bytes), pero si su sistema operativo buscara el sector 2048 (4096 bytes), no ¡Encuentra el inicio de esa partición! Te has encontrado con este problema. Como tal, su pensamiento inicial de que es culpa del gabinete USB está más cerca de la realidad que su pensamiento más reciente de que su placa base lo estropeó. Yo nunca He oído hablar de una placa base que traduce el tamaño del sector de esta manera. (Sin embargo, algunos dispositivos RAID de hardware lo hacen).

No conozco una forma de obligar a Linux a ajustar su idea del tamaño del sector, pero si tiene suficiente espacio en disco, puede ser útil hacer una copia de disco de bajo nivel a otro disco. Por ejemplo:

dd if=/dev/sdb of=~/image.img

Esto copiará su disco desde /dev/sdb (el disco USB; ajustar según sea necesario) al archivo ~/image.img . Luego puede usar el siguiente script para montar las particiones de la imagen:

#!/bin/bash
gdisk -l $1 > /tmp/mount_image.tmp
let StartSector=`egrep "^   $2|^  $2" /tmp/mount_image.tmp | fmt -u -s | sed -e 's/^[ \t]*//' | head -1 | cut -d " " -f 2`

let StartByte=($StartSector*512)

echo "Mounting partition $2, which begins at sector $StartSector"

mount -o loop,offset=$StartByte $1 $3

rm /tmp/mount_image.tmp

Guarde el script como, digamos, mount_image y úsalo así:

./mount_image ~/image.img 2 /mnt

Esto montará la partición 2 de image.img a /mnt . Tenga en cuenta que la secuencia de comandos se basa en GPT fdisk (gdisk ), que la mayoría de las distribuciones incluyen en un paquete llamado gptfdisk o gdisk .

A la larga, una mejor solución es encontrar una manera de conectar el disco que no haga la traducción del tamaño del sector. Una conexión directa a una placa base nueva debería funcionar; o probablemente pueda encontrar un gabinete externo que no haga la traducción. De hecho, algunos gabinetes hacen la traducción en los puertos USB pero no en los puertos eSATA, por lo que si su gabinete tiene un puerto eSATA, podría intentar usarlo. Me doy cuenta de que es probable que todas estas soluciones cuesten dinero, que usted dice que no tiene, pero tal vez pueda cambiar su gabinete de traducción por uno que no hace la traducción.

Otra opción que se me ocurre es probar con una máquina virtual como VirtualBox. Tal herramienta podría asumir un tamaño de sector de 512 bytes al acceder al dispositivo de disco, deshaciendo efectivamente la traducción; o es posible que pueda copiar el contenido del disco sin formato (como en dd if=/dev/sdc of=/dev/sdb ) dentro de la máquina virtual, que podría copiar el contenido con compresión, lo que permite que la imagen quepa en menos espacio en disco que el que consume el original.

Este script generalizó la propuesta de Rod Smith, cuando tienes una redada o una criptografía. No hay garantía. ¡Anímate a mejorarlo! (Actualizado con los últimos hallazgos sobre mdadm)

#!/bin/sh
#
# This script solve the following problem:
#
# 1. create a GPT partition on a large disk while attached directly via SATA
#    when the device present itself with 512 bytes of block size:
#    sd 3:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 2. try to use a SATA to USB adapter like ID 067b:2773 Prolific Technology, Inc.
#    this present the device with 4096 bytes of block size:
#    sd 19:0:0:0: [sdc] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 3. The kernel is unable to read correctly the partition table with
#    the USB adaper.
#
#
# With the current tools (kernel and gdisk) in debian wheezy is
# possible to use losetup to remap the partitions to loop devices so
# you can use them as usual with any filesystem, raid or crypto
#
# I still do not know if this issue is originated by the adapter or by
# the disk and if there are any others workarounds.
#
# Known version of the software:
# $ apt-show-versions linux-image-3.2.0-4-amd64
# linux-image-3.2.0-4-amd64/wheezy uptodate 3.2.54-2
# $ apt-show-versions gdisk
# gdisk/wheezy uptodate 0.8.5-1


attach_device() {

    device="$1";

    MYTMPDIR=`mktemp -d`
    trap "rm -rf $MYTMPDIR" EXIT

    # gdisk on the device use the 4096 sector size
    # but we need to force it to 512
    # this is a knwon workaround from http://superuser.com/a/679800
    # basically we make a copy of the gpt partition table on a file
    dd if="/dev/$device" bs=16384 count=1 of="$MYTMPDIR/gpt" 2> /dev/null

    # we extract the offset and the size of each partition
    #
    # FIXME: the "+ 1" seems strange, but it is needed to get the same
    #        size value from:
    #
    #        blockdev --getsize64
    #
    #        without the "+ 1" some funny things happens, for example
    #        you will not be able to start a recognized md device:
    #
    #        md: loop1 does not have a valid v1.2 superblock, not importing!
    #        md: md_import_device returned -22
    #
    #        even if
    #
    #        mdadm --examine /dev/loop1
    #
    #        does not complaint

    gdisk -l \
     "$MYTMPDIR/gpt" 2> /dev/null | \
     awk '/^ *[0-9]/ {printf "%.0f %.0f\n", $2 * 512, ($3 - $2 + 1) * 512}' > $MYTMPDIR/offset-size

    # we create a loop device with the give offset and size
    while read line;
    do
        offset=$(printf "$line" | cut -d ' ' -f 1);
        size=$(printf "$line" | cut -d ' ' -f 2);
        losetup --verbose --offset "$offset" --sizelimit "$size" `losetup -f` /dev/$device;
    done < $MYTMPDIR/offset-size;
}

detach_device() {

    device="$1";

    for loopdevice in `losetup -a | grep "$device" | cut -d : -f 1`;
    do
        losetup --verbose --detach "$loopdevice";
    done;
}

usage() {
cat <<EOF
Usage:
- $0 -h to print this help
- $0 sda to attach the gpt partitions of sda
- $0 -d sda to detach the gpt partitions of sda
EOF
}


detach=0;

while getopts hd action
do
    case "$action" in
        d) detach=1;;
        h) usage;;
    esac
done
shift $(($OPTIND-1))

if [ $# -ne 1 ];
then
    usage;
fi

if [ "x$detach" = "x0" ]; then
    attach_device $1;
else
    detach_device $1;
fi

Tuve este problema cuando extraje un disco de 4 TB de una carcasa externa WD My Book. El problema es:

1. la tabla de particiones MBR está errada por un factor de 8 y
2. la tabla de particiones MBR no puede manejar>2 TB cuando el tamaño del sector es 512.

Solución: Vuelva a escribir la tabla de particiones en un GPT, convirtiendo los valores para usar sectores de 512 bytes.

En mi caso, la partición comenzó con un desplazamiento de 1 MB y finalizó (~ 856 kB) antes del final del disco. Esto es bueno porque permitió el MBR+GPT (17408 bytes) antes de la partición y el GPT de respaldo (16896 bytes) al final del disco.

Hice imágenes de ambas regiones por si acaso (usando dd).

Tomé nota de la salida de fdisk -l /dev/sde .

Usé gdisk para eliminar la primera partición. Si lo desea, puede hacer lo que hice yo y cambiar el valor de alineación a 8 (4096) para usar la mayor cantidad de espacio posible. Luego, creé una nueva partición con el inicio en 2048 y el final al final del disco. Ampliaré el sistema de archivos más tarde.

Afortunadamente, el cambio en el tamaño del sector no afecta el sistema de archivos, LVM o LUKS.