Actualización final:

Ya sabía lo que tenía que hacer para solucionar este problema; Simplemente no sabía cómo hacerlo. Esperaba que hubiera alguna herramienta lista para hacerlo automáticamente, pero no pude encontrar ninguna. Acepto la respuesta de Rod porque, a pesar de no resolver directamente mi problema, proporciona una muy buena información sobre el problema del tamaño del sector y me dio la confianza de que el problema realmente era la alineación y el direccionamiento de la partición. Para aquellos que llegan a esta pregunta que tienen el mismo problema, léalo detenidamente y cuidadosamente, incluidos los comentarios, antes de hacer nada.

Al principio

Tenía una computadora y necesitaba más espacio, compré una nueva unidad de 500 GB y una carcasa USB. Pronto me di cuenta de que si particionaba la unidad en el gabinete y la movía a la computadora, no reconocería las particiones (y viceversa). Asumí que era un problema con el gabinete y no me preocupé por eso.

Entonces, tragedia

Un día maravilloso, mi computadora decidió no encender más. Resulta que la placa base (sin marca, solo una gran MADE IN CHINA impresa en ella) está muerta. Lo he estado usando como servidor de archivos y esa unidad de 500 GB ahora está llena de datos que no puedo permitirme perder. Ahora estoy en bancarrota y no puedo pagar una computadora nueva, así que mi única esperanza era la carcasa USB "defectuosa".

La investigación

Armado con varias distribuciones de Linux, una computadora portátil, VirtualBox y el gabinete, hice un análisis forense sobre el tema. dmesg informó que el tamaño de la partición estaba más allá del final de la unidad. Así que revisé las hojas de datos del disco duro, recuentos de sectores calculados desde cero, probé los límites de la unidad manualmente con dd, y todo parecía estar bien, hasta que encendí fdisk y dijo:

    Note: Sector size is 4096 (not 512).

Qué modesto de fdisk. Esta "nota" fue la raíz de todos los problemas. Después de un poco más de violín se sacaron estas conclusiones:

• La carcasa USB no está defectuosa.

• El controlador SATA en la placa base ahora muerta es el que era "extraño", al menos. No informó sectores de 4096 bytes al sistema operativo, por lo que el sistema operativo creó felizmente el MBR utilizando direcciones de sector de 512 bytes.

• Ahora, cuando intento acceder a la partición, el sistema operativo intenta usar las direcciones basadas en 512 bytes en una unidad de sector de 4096 bytes y, por supuesto, no funcionará.

La pregunta

• Entonces, ¿cómo puedo corregir las direcciones en el MBR para que sean válidas en un tamaño de sector de 4096 bytes, además de editar manualmente el MBR en un editor hexadecimal, y

• Las particiones no están alineadas para sectores de 4096 bytes. ¿Hay alguna herramienta disponible para alinearlos además de copiar dentro y fuera de otra unidad? (No tengo unidades de repuesto), ¿o tendré que crear alguna herramienta que "desplace" los datos a un lado un poco a la vez? Las particiones son ext3.

¡Gracias!

Actualizar:

Descubrí que hay una manera inteligente de usar dd para cambiar la partición en su lugar en esta pregunta: ¿Cómo mover una partición en GNU / Linux? Sin embargo, no sé si funcionará en una porción de un sector. No puedo probarlo ahora, pero lo haré cuando tenga algo de tiempo.

Actualización 2:

Así que alineé con éxito la partición usando el método anterior y edité manualmente el MBR en un editor hexadecimal. ¡Tan pronto como volví a enchufar el HDD, la partición de brazo se montó automáticamente! Sin embargo, no recomiendo esto, hubo errores de E / S durante el proceso y podría haberlo perdido todo, vea el comentario sobre la respuesta de Rod. Para la otra partición, no me arriesgaré y utilizaré un disco duro antiguo y alinearé los fragmentos a la vez copiando los datos y luego pegándolos nuevamente en una posición diferente.

Los problemas de tamaño del sector se están volviendo bastante complejos. Hasta finales de 2009, la gran mayoría de los discos duros usaban sectores de 512 bytes, y eso fue todo. A finales de 2009, los fabricantes de discos comenzaron a introducir los llamados discos de 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 sector físico de 4096 bytes dividido en ocho sectores lógicos de 512 bytes . 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, casi con certeza 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, ciertos alojamientos de disco 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 2TiB se pueden usar con el antiguo sistema de partición MBR. Una desventaja importante es que un disco particionado en uno de estos gabinetes no puede usarse 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 usar cuando se transfiere a dicho gabinete. Tenga en cuenta que este problema va mucho más allá del MBR mismo; su disco podría identificar la primera partición como comenzando en el sector 2048 (512 bytes), pero si su sistema operativo buscara el sector 2048 (4096 bytes),encuentra el comienzo 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 marca que su pensamiento más reciente de que su placa base la estropeó. He Nunca oí de un tamaño de sector traducción placa base de esta manera. (Sin embargo, algunos dispositivos RAID de hardware lo hacen).

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

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

Esto copiará su disco desde /dev/sdb(el disco USB; ajústelo 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 la secuencia de comandos como, digamos, mount_imagey úsela así:

./mount_image ~/image.img 2 /mnt

Esto montará la partición 2 de image.imga /mnt. Tenga en cuenta que el script se basa en GPT fdisk ( gdisk) , que la mayoría de las distribuciones incluyen en un paquete llamado gptfdisko 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 nueva placa base debería hacer el truco; o probablemente pueda encontrar un recinto externo que no haga la traducción. De hecho, algunos gabinetes hacen la traducción en puertos USB pero no en puertos eSATA, por lo que si su gabinete tiene un puerto eSATA, puede intentar usarlo. Me doy cuenta de que es probable que todas estas soluciones cuesten dinero, lo que usted dice que no tiene, pero tal vez pueda cambiar su gabinete de traducción por uno que no haga la traducción.

Otra opción que se me ocurre es intentar usar una máquina virtual como VirtualBox. Dicha herramienta podría asumir un tamaño de sector de 512 bytes al acceder al dispositivo de disco, deshaciendo efectivamente la traducción; o puede copiar los contenidos del disco sin procesar (como en dd if=/dev/sdc of=/dev/sdb) dentro de la máquina virtual, lo que podría copiar los contenidos con compresión, permitiendo así que la imagen se ajuste a menos espacio en el disco que el original.

Este script generaliza la propuesta de Rod Smith, cuando tienes una redada o una criptografía. Sin garantía. ¡Siéntete libre de mejorarlo! (Actualizado con el último hallazgo 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

Otra forma bastante sencilla de hacer esto es usar la función de rescate de parted. Sin embargo, esto requiere que cree una nueva etiqueta de disco, por lo que implica riesgos. Parted actúa directamente en el disco, así que haga copias de seguridad según sea necesario antes de ejecutar parted. Entonces empezar:

parted /dev/sdb

Parted le dirá algo en este sentido cuando intente leer un disco con un tamaño de sector diferente al que creó la tabla de particiones:

Error: /dev/sdb: unrecognised disk label                                  

Use mklabel para crear un nuevo MBR o GPT de acuerdo con lo que utilizó anteriormente

(parted) mklabel
New disk label type? mbr

Luego ejecute el rescate para encontrar su antigua partición

(parted) rescue
Start? 0
End? 4001GB
Information: A ext4 primary partition was found at 1049kB -> 2000GB.  Do you
want to add it to the partition table?
Yes/No/Cancel? y

Repita el proceso de rescate si tiene más particiones. Ya has terminado.

Tuve este problema cuando quité un disco de 4TB de un gabinete externo WD My Book. El problema es:

1. la tabla de particiones MBR está desactivada 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: reescriba la tabla de particiones en un GPT, convirtiendo los valores para usar sectores de 512 bytes.

En mi caso, la partición comenzó en un desplazamiento de 1 MB y terminó (~ 856kB) 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 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. Haré crecer 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.