Atualização final:

Eu já sabia o que precisava fazer para corrigir esse problema; Eu simplesmente não sabia como fazê-lo. Eu esperava que houvesse alguma ferramenta pronta para fazer isso automaticamente - mas não consegui encontrar nenhuma. Estou aceitando a resposta de Rod porque, apesar de não resolver diretamente o meu problema, ele fornece um histórico muito bom sobre o tamanho do setor e me deu confiança de que o problema era realmente o alinhamento e o endereçamento de partições. Para aqueles que chegam a esta pergunta com o mesmo problema, leia-a com atenção e detalhes, incluindo comentários, antes de fazer qualquer coisa.

No início

Eu tinha um computador e, precisando de mais espaço, comprei uma nova unidade de 500 GB e um gabinete USB. Logo percebi que, se particionasse a unidade no gabinete e a movesse para o computador, ela não reconheceria as partições (e vice-versa). Eu assumi que era um problema com o gabinete e não me preocupei.

Então, tragédia

Um dia maravilhoso, meu computador decidiu não ligar mais. Acontece que a placa-mãe (sem marca, apenas uma grande MADE IN CHINA impressa nela) está morta. Estou usando-o como um servidor de arquivos e agora a unidade de 500 GB está cheia de dados que não posso perder. Agora estou sem dinheiro e não posso comprar um computador novo, então minha única esperança era o gabinete USB "defeituoso".

A investigação

Armado com várias distribuições Linux, um laptop, o VirtualBox e o gabinete, fiz uma análise forense sobre o assunto. O dmesg relatou que o tamanho da partição estava além do final da unidade. Então, examinei as planilhas de dados do disco rígido, calculei as contagens do setor a partir do zero, testei os limites da unidade manualmente com dd e tudo parecia bem, até que eu iniciei o fdisk e ele disse:

    Note: Sector size is 4096 (not 512).

Como modesto do fdisk. Esta "nota" foi a raiz de todos os problemas. Depois de mais algumas brincadeiras, essas conclusões foram tiradas:

• O gabinete USB não está com defeito.

• O controlador SATA na placa-mãe agora morta é o que era "estranho", pelo menos. Como não relatou setores de 4096 bytes no sistema operacional, o sistema operacional criou o MBR com prazer usando endereços de setor de 512 bytes.

• Agora, quando tento acessar a partição, o sistema operacional tenta usar os endereços baseados em 512 bytes em uma unidade do setor de 4096 bytes e, é claro, isso não vai funcionar.

A questão

• Portanto, como posso corrigir os endereços no MBR para que sejam válidos em um tamanho de setor de 4096 bytes, além de editar manualmente o MBR em um editor hexadecimal e

• As partições não estão alinhadas para setores de 4096 bytes. Existe alguma ferramenta disponível para alinhá-los, além de copiar dentro e fora de outra unidade? (Não tenho unidades sobressalentes), ou precisarei criar alguma ferramenta que "mude" os dados para o lado, um pouco por vez? Partições são ext3.

Obrigado!

Atualizar:

Eu descobri que existe uma maneira inteligente de usar o dd para mudar a partição no lugar nesta pergunta: Como mover uma partição no GNU / Linux? Mas não sei se funcionará em uma fatia de um setor. Não posso testá-lo agora, mas o farei quando tiver algum tempo.

Atualização 2:

Então, eu alinhei com sucesso a partição usando o método acima e editei o MBR manualmente em um editor hexadecimal. Assim que eu reconectei o HDD, a partição da lança foi montada automaticamente! Porém, eu não recomendo isso, houve erros de E / S durante o processo e eu poderia ter perdido tudo, veja o comentário na resposta de Rod. Para a outra partição, não correrei riscos e usarei um disco rígido antigo e alinhe os pedaços por vez, copiando os dados e colando-os novamente em uma posição diferente.

As questões de tamanho do setor estão se tornando bastante complexas. Até o final de 2009, a grande maioria dos discos rígidos usava setores de 512 bytes, e era isso. No final de 2009, os fabricantes de discos começaram a introduzir os chamados discos Advanced Format (AF), que usam setores de 4096 bytes. Esses primeiros discos AF (e, AFAIK, todos os discos AF atuais) apresentam uma interface para o computador que mostra cada setor físico de 4096 bytes como sendo dividido em oito setores lógicos de 512 bytes . Essa conversão permite que ferramentas mais antigas, incluindo muitos BIOS, construídas com premissas de 512 bytes, continuem funcionando. Não sei se o seu disco usa AF ou não, mas em ambos os casos, quase certamente usa um tamanho de setor lógico de 512 bytes, o que significa que a interface do sistema operacional deve usar setores de 512 bytes.

Para complicar, há alguns compartimentos de disco USB. Alguns desses gabinetes fazem o inverso do que o AF faz: pegam oito setores de disco e os agrupam em um novo setor de 4096 bytes. Não sei ao certo qual é o raciocínio por trás dessa mudança, mas uma vantagem prática é que discos maiores que 2TiB podem ser usados ​​com o antigo sistema de particionamento MBR. Uma grande desvantagem é que um disco particionado em um desses gabinetes não pode ser usado diretamente ou em um gabinete que não faz esse tipo de conversão. Da mesma forma, um disco preparado sem essa tradução não pode ser usado quando é transferido para esse gabinete. Observe que esse problema vai muito além do próprio MBR; seu disco pode identificar a primeira partição como iniciando no setor (512 bytes) 2048, mas se o seu sistema operacional procurar o setor (4096 bytes) 2048,encontre o início dessa partição! Você já encontrou esse problema. Como tal, o seu pensamento inicial de que a falha do gabinete USB está mais próximo da marca do que o seu pensamento mais recente de que sua placa-mãe estragou tudo. Eu nunca ouvi falar de uma placa-mãe traduzindo o tamanho do setor dessa maneira. (Alguns dispositivos RAID de hardware o fazem.)

Não conheço uma maneira de forçar o Linux a ajustar sua idéia do tamanho do setor, mas se você tiver espaço em disco suficiente, fazer uma cópia de baixo nível em outro disco pode ajudar. Por exemplo:

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

Isso copiará seu disco de /dev/sdb(o disco USB; ajuste conforme necessário) para o arquivo ~/image.img. Você pode usar o seguinte script para montar as partições da imagem:

#!/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

Salve o script como, digamos, mount_imagee use-o assim:

./mount_image ~/image.img 2 /mnt

Isso montará a partição 2 de image.imgpara /mnt. Observe que o script depende do GPT fdisk ( gdisk) , que a maioria das distribuições inclui em um pacote chamado gptfdiskou gdisk.

A longo prazo, uma solução melhor é encontrar uma maneira de conectar o disco que não fará a conversão em tamanho de setor. Uma conexão direta com uma nova placa-mãe deve funcionar; ou você provavelmente pode encontrar um gabinete externo que não faz a tradução. De fato, alguns gabinetes fazem a conversão nas portas USB, mas não nas portas eSATA; portanto, se o seu gabinete possui uma porta eSATA, você pode tentar usá-lo. Sei que todas essas soluções provavelmente custam dinheiro, o que você diz não ter, mas talvez possa trocar seu gabinete de tradução por um que não faça a tradução.

Outra opção que me ocorre é tentar usar uma máquina virtual como o VirtualBox. Essa ferramenta pode assumir um tamanho de setor de 512 bytes ao acessar o dispositivo de disco, desfazendo efetivamente a tradução; ou você pode copiar o conteúdo do disco bruto (como em dd if=/dev/sdc of=/dev/sdb) na máquina virtual, o que pode copiar o conteúdo com compactação, permitindo que a imagem caiba em menos espaço em disco do que o original consome.

Esse script generalizou a proposta de Rod Smith, quando você tem uma invasão ou uma criptografia. Sem garantia. Sinta-se livre para melhorá-lo! (Atualizado com a última descoberta sobre o 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

Outra maneira bastante direta de fazer isso é usar a função de resgate do parted. Isso requer que você crie um novo rótulo de disco, portanto, isso envolve riscos. O Parted atua diretamente no disco, portanto faça backups conforme necessário antes de executar o Parted. Então comece:

parted /dev/sdb

O parted informará algo nesse sentido ao tentar ler um disco com tamanho de setor diferente daquele com o qual a tabela de partição foi criada:

Error: /dev/sdb: unrecognised disk label                                  

Use mklabel para criar um novo MBR ou GPT de acordo com o que você usou anteriormente

(parted) mklabel
New disk label type? mbr

Em seguida, execute o resgate para encontrar sua partição antiga

(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 o processo de resgate se você tiver mais partições. Você está pronto agora.

Eu tive esse problema ao remover um disco de 4 TB de um gabinete externo do WD My Book. O problema é:

1. a tabela de partição MBR está desativada por um fator de 8 e
2. a tabela de partição MBR não pode manipular> 2 TB quando o tamanho do setor é 512.

Solução: reescreva a tabela de partição em uma GPT, convertendo os valores para usar setores de 512 bytes.

No meu caso, a partição começou com um deslocamento de 1 MB e terminou (~ 856kB) antes do final do disco. Isso é bom porque permitiu o MBR + GPT (17408 bytes) antes da partição e o GPT de backup (16896 bytes) no final do disco.

Eu fiz imagens de ambas as regiões por precaução (usando dd).

Eu notei a saída de fdisk -l /dev/sde.

Eu usei o gdisk para excluir a primeira partição. Se desejar, você pode fazer o que eu fiz e alterar o valor do alinhamento para 8 (4096) para usar o máximo de espaço possível. Então, criei uma nova partição com o início em 2048 e o final no final do disco. Vou aumentar o sistema de arquivos mais tarde.

Felizmente, a alteração no tamanho do setor não afeta o sistema de arquivos, o LVM ou o LUKS.