Come correggere l'MBR di settore da 512 byte su un disco di settore da 4096 byte?

Le questioni relative alle dimensioni del settore stanno diventando piuttosto complesse. Fino alla fine del 2009, la stragrande maggioranza dei dischi rigidi utilizzava settori da 512 byte, e basta. Alla fine del 2009, i produttori di dischi hanno iniziato a introdurre il cosiddetto Formato avanzato (AF), che utilizzano settori da 4096 byte. Questi primi dischi AF (e, AFAIK, tutti i dischi AF oggi) presentano un'interfaccia per il computer che mostra ogni fisico da 4096 byte settore come suddiviso in otto logici da 512 byte settori. Questa conversione consente agli strumenti meno recenti, inclusi molti BIOS, creati con presupposti di 512 byte, di continuare a funzionare. Non so se il tuo disco utilizza AF o meno, ma in entrambi i casi utilizza quasi certamente una dimensione di settore logico di 512 byte, il che significa che l'interfaccia del sistema operativo dovrebbe utilizzare settori di 512 byte.

A complicare le cose ci sono alcune custodie per dischi USB. Alcuni di questi contenitori fanno il contrario di ciò che fa AF:prendono otto settori del disco e li raggruppano in un nuovo settore da 4096 byte. Non sono sicuro di quale sia il ragionamento alla base di questa mossa, ma un vantaggio pratico è che i dischi più grandi di 2TiB possono essere utilizzati con il vecchio sistema di partizionamento MBR. Uno dei principali svantaggi è che un disco partizionato in uno di questi contenitori non può essere utilizzato direttamente o in un contenitore che non esegue questo tipo di traduzione. Allo stesso modo, un disco preparato senza questa traduzione non può essere utilizzato quando viene trasferito in un contenitore di questo tipo. Si noti che questo problema va ben oltre l'MBR stesso; il tuo disco potrebbe identificare la prima partizione che inizia nel settore (512 byte) 2048, ma se il tuo sistema operativo cercasse nel settore (4096 byte) 2048, non trova l'inizio di quella partizione! Ti sei imbattuto in questo problema. Pertanto, il tuo pensiero iniziale che sia colpa dell'enclosure USB è più vicino al segno rispetto al tuo pensiero più recente che la tua scheda madre ha incasinato tutto. mai sentito parlare di una scheda madre che traduce le dimensioni del settore in questo modo. (Alcuni dispositivi RAID hardware lo fanno, però.)

Non conosco un modo per forzare Linux ad adattare la sua idea della dimensione del settore, ma se si dispone di spazio su disco sufficiente, può essere utile eseguire una copia del disco di basso livello su un altro disco. Ad esempio:

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

Questo copierà il tuo disco da /dev/sdb (il disco USB; regolare se necessario) nel file ~/image.img . È quindi possibile utilizzare il seguente script per montare le partizioni dell'immagine:

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

Salva lo script come, ad esempio, mount_image e usalo in questo modo:

./mount_image ~/image.img 2 /mnt

Questo monterà la partizione 2 di image.img a /mnt . Tieni presente che lo script si basa su fdisk GPT (gdisk ), che la maggior parte delle distribuzioni include in un pacchetto chiamato gptfdisk o gdisk .

A lungo termine, una soluzione migliore è trovare un modo per collegare il disco che non eseguirà la traduzione delle dimensioni del settore. Una connessione diretta a una nuova scheda madre dovrebbe bastare; o probabilmente puoi trovare un allegato esterno che non esegue la traduzione. In effetti, alcuni contenitori eseguono la traduzione su porte USB ma non su porte eSATA, quindi se il tuo contenitore ha una porta eSATA, puoi provare a usarla. Mi rendo conto che è probabile che queste soluzioni costino denaro, cosa che tu dici di non avere, ma forse puoi scambiare il tuo allegato di traduzione con uno che non esegue la traduzione.

Un'altra opzione che mi viene in mente è provare a utilizzare una macchina virtuale come VirtualBox. Tale strumento potrebbe assumere una dimensione del settore di 512 byte quando si accede al dispositivo del disco, annullando di fatto la traduzione; oppure potresti essere in grado di copiare i contenuti del disco non elaborati (come in dd if=/dev/sdc of=/dev/sdb ) all'interno della macchina virtuale, che potrebbe copiare i contenuti con compressione, consentendo così all'immagine di occupare meno spazio su disco rispetto a quello consumato dall'originale.

Questo script ha generalizzato la proposta di Rod Smith, quando hai un raid o una crittografia. Nessuna garanzia. Sentiti libero di migliorarlo! (Aggiornato con le ultime scoperte su 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

Ho riscontrato questo problema quando ho rimosso un disco da 4 TB da un contenitore esterno WD My Book. Il problema è:

1. la tabella delle partizioni MBR è discosta di un fattore 8 e
2. la tabella delle partizioni MBR non può gestire>2 TB quando la dimensione del settore è 512.

Soluzione: Riscrivi la tabella delle partizioni in un GPT, convertendo i valori per utilizzare settori da 512 byte.

Nel mio caso la partizione è iniziata con un offset di 1 MB ed è terminata (~ 856kB) prima della fine del disco. Questo è positivo perché consente l'MBR+GPT (17408 byte) prima della partizione e il GPT di backup (16896 byte) alla fine del disco.

Ho creato immagini di entrambe le regioni per ogni evenienza (usando dd).

Ho notato l'output di fdisk -l /dev/sde .

Ho usato gdisk per eliminare la prima partizione. Se vuoi, puoi fare come ho fatto io e cambiare il valore di allineamento a 8 (4096) per usare più spazio possibile. Quindi, ho creato una nuova partizione con l'inizio al 2048 e la fine alla fine del disco. Farò crescere il file system più tardi.

Per fortuna, la modifica della dimensione del settore non influisce sul file system, LVM o LUKS.