Como corrigir o MBR do setor de 512 bytes em um disco de setor de 4096 bytes?

21

Atualização final:

Eu já sabia o que precisava fazer para corrigir esse problema; Eu simplesmente não sabia como fazê-lo. Eu estava esperando que houvesse alguma ferramenta pronta para fazer isso automaticamente - mas não encontrei nenhuma. Estou aceitando a resposta de Rod porque, apesar de não resolver diretamente o meu problema, ele fornece uma boa base sobre a questão do 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 essa questão com o mesmo problema, leia-o minuciosamente e com cuidado, incluindo comentários, antes de fazer qualquer coisa.

No começo

Eu tinha um computador e precisava de mais espaço. Comprei um novo disco de 500 GB e um compartimento USB. Logo notei que se eu particionasse a unidade no gabinete e a movesse para o computador, ela não reconheceria as partições (e vice-versa). Eu presumi que era um problema com o gabinete e não me preocupei com isso.

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 impressa MADE IN CHINA) está morta. Eu tenho usado isso como um servidor de arquivos e essa unidade de 500 GB agora está cheia de dados que eu não posso perder. Estou quebrado agora e não posso comprar um novo computador, 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 tamanho da partição reportada pelo dmesg estava além do fim da unidade. Então eu passei pelas folhas de dados do disco rígido, calculei as contagens do setor do zero, testei os limites da unidade manualmente com o dd, e tudo parecia OK, até que atirei o fdisk e ele disse:

    Note: Sector size is 4096 (not 512).

Quão modesto é o fdisk. Esta "nota" foi a raiz de todos os problemas. Depois de mais algumas tentativas, essas conclusões foram tiradas:

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

  • O controlador SATA na placa-mãe já morta é aquele que era "estranho", pelo menos. Ele não relatou setores de 4096 bytes para o sistema operacional, portanto, o sistema operacional criou com alegria o MBR 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 de setor de 4096 bytes e, claro, isso não funcionará.

A questão

  • Então, como posso corrigir os endereços no MBR para que eles 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 e sair de outra unidade? (Eu não tenho unidades sobressalentes), ou precisarei criar alguma ferramenta que "desloque" os dados para o lado um pouco por vez? As partições são ext3.

Obrigado!

Atualização:

Descobri que existe uma maneira inteligente de usar o dd para deslocar a partição in-loco nesta questão: Como mover uma partição no GNU / Linux? Mas eu não sei se vai funcionar em uma fatia de um setor, no entanto. Eu não posso testá-lo agora, mas farei quando tiver algum tempo.

Atualização 2:

Portanto, alinhei a partição com sucesso usando o método acima e editei manualmente o MBR em um editor hexadecimal. Assim que eu voltar a ligar o HDD, a partição boom é montada automaticamente! Eu não recomendo isso, porém, houve erros de E / S durante o processo e eu poderia ter perdido tudo, veja o comentário sobre a resposta de Rod. Para a outra partição, não assumirei riscos e utilizarei um disco rígido antigo e alinarei pedaços de cada vez, copiando os dados e colando-os em uma posição diferente.

    
por NothingsImpossible 23.11.2013 / 15:10

4 respostas

24

As questões do 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 foi 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 hoje) apresentam uma interface para o computador que mostra cada setor físico de 4096 bytes como sendo dividido em oito <5> lógicas setores. Essa conversão permite que ferramentas mais antigas, incluindo muitas BIOS, que foram criadas com suposições de 512 bytes, continuem funcionando. Eu não sei se o seu disco usa AF ou não, mas em qualquer caso, quase certamente usa um tamanho de setor lógico de 512 bytes, o que significa que a interface para o sistema operacional deve usar setores de 512 bytes.

A complicar é a questão de certos compartimentos de disco USB. Alguns desses compartimentos fazem o inverso do que o AF faz: eles pegam oito setores de disco e os agrupam em um novo setor de 4096 bytes. Não tenho certeza de 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 faça esse tipo de conversão. Da mesma forma, um disco preparado sem essa tradução não pode ser usado quando é transferido para tal gabinete. Note que este problema vai muito além do próprio MBR; seu disco pode identificar a primeira partição como começando em (512 bytes) setor 2048, mas se o seu sistema operacional fosse procurar o setor (2096-byte) 2048, ele não encontraria o início dessa partição ! Você se deparou com esse problema. Como tal, o seu pensamento inicial de que é a falha do invólucro USB está mais próximo da marca do que 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 fazem isso, no entanto.)

Eu não sei como 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 disco de baixo nível para 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 então 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, por exemplo, mount_image e use-o da seguinte forma:

./mount_image ~/image.img 2 /mnt

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

A longo prazo, uma solução melhor é encontrar uma maneira de conectar o disco que não fará a tradução do tamanho do setor. Uma conexão direta com uma nova placa-mãe deve fazer o truque; ou você provavelmente encontrará um gabinete externo que não faz a tradução. Na verdade, alguns gabinetes fazem a tradução em portas USB, mas não em portas eSATA, portanto, se o seu gabinete tiver uma porta eSATA, você poderá tentar usá-lo. Eu percebo que é provável que todas essas soluções custem dinheiro, o que você diz que não tem, mas talvez você possa trocar o seu espaço 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. Tal ferramenta pode assumir um tamanho de setor de 512 bytes ao acessar o dispositivo de disco, efetivamente desfazendo 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, 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.

    
por 23.11.2013 / 19:59
4

Este script generalizou a proposta do Rod Smith, quando você tem um ataque ou uma criptografia. Sem garantia. Sinta-se livre para melhorá-lo! (Atualizado com a descoberta mais recente 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
    
por 23.02.2014 / 22:43
2

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

parted /dev/sdb

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 o 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á feito agora.

    
por 16.11.2015 / 14:43
2

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

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

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

No meu caso, a partição começou em um deslocamento de 1MB e terminou (~ 856kB) antes do final do disco. Isso é bom porque, em seguida, ele 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 apenas no caso (usando dd).

Eu observei 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 de alinhamento para 8 (4096) para usar o máximo de espaço possível. Em seguida, criei uma nova partição com o início em 2048 e o final no final do disco. Eu crescerei o sistema de arquivos mais tarde.

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

    
por 01.05.2016 / 17:09