Come correggere un MBR di settore a 512 byte su un disco di settore a 4096 byte?


23

Aggiornamento finale:

Sapevo già cosa dovevo fare per risolvere questo problema; Non sapevo proprio come farlo. Speravo che ci fosse uno strumento già pronto per farlo automaticamente, ma non sono riuscito a trovarne. Sto accettando la risposta di Rod perché, nonostante non risolva direttamente il mio problema, fornisce un ottimo background sulla questione delle dimensioni del settore e mi ha dato la certezza che il problema riguardava davvero l'allineamento e la risoluzione delle partizioni. Per coloro che arrivano a questa domanda con lo stesso problema, leggilo attentamente e attentamente, inclusi i commenti, prima di fare qualsiasi cosa.


All'inizio

Avevo un computer e avevo bisogno di più spazio. Ho comprato una nuova unità da 500 GB e una custodia USB. Presto ho notato che se avessi partizionato l'unità sul contenitore e spostato sul computer, non avrebbe riconosciuto le partizioni (e viceversa). Ho pensato che fosse un problema con la custodia e non me ne sono preoccupato.

Quindi, tragedia

Un giorno meraviglioso, il mio computer ha deciso di non accendersi più. Si scopre che la scheda madre (senza marchio, solo un grande MADE IN CHINA stampato su di essa) è morta. L'ho usato come file server e quell'unità da 500 GB è ora piena di dati che non posso permettermi di perdere. Ora sono al verde e non posso permettermi un nuovo computer, quindi la mia unica speranza era la custodia USB "difettosa".

L'investigazione

Armato di diverse distribuzioni Linux, un laptop, VirtualBox e il contenitore ho fatto un'analisi forense sulla questione. dmesg ha riferito che la dimensione della partizione era oltre la fine del drive. Quindi ho esaminato i fogli dati del disco rigido, ho calcolato i conteggi dei settori da zero, ho testato manualmente i limiti del disco con dd e tutto è andato bene, fino a quando ho acceso fdisk e ha detto:

    Note: Sector size is 4096 (not 512).

Che modesto fdisk. Questa "nota" è stata la radice di tutti i problemi. Dopo qualche altro giocherellamento furono tratte queste conclusioni:

  • La custodia USB non è difettosa.

  • Il controller SATA sulla scheda madre ormai morta è almeno quello "strano". Non ha segnalato i settori a 4096 byte al sistema operativo, quindi il sistema operativo ha creato felicemente l'MBR utilizzando indirizzi di settore a 512 byte.

  • Ora, quando provo ad accedere alla partizione, il sistema operativo tenta di utilizzare gli indirizzi basati su 512 byte su un'unità settoriale da 4096 byte e, naturalmente, non funzionerà.

La domanda

  • Quindi, come posso correggere gli indirizzi nell'MBR in modo che siano validi su una dimensione del settore di 4096 byte, oltre a modificare manualmente l'MBR su un editor esadecimale, e

  • Le partizioni non sono allineate per settori a 4096 byte. C'è qualche strumento disponibile per allinearli oltre alla copia dentro e fuori da un'altra unità? (Non ho unità di riserva), o dovrò creare uno strumento che "sposta" i dati lateralmente un po 'alla volta? Le partizioni sono ext3.

Grazie!

Aggiornare:

Ho scoperto che esiste un modo intelligente di usare dd per spostare la partizione sul posto in questa domanda: Come spostare una partizione in GNU / Linux? Ma non so se funzionerà su una fetta di un settore, però. Non posso provarlo adesso, ma lo farò quando avrò del tempo.

Aggiornamento 2:

Quindi ho allineato con successo la partizione usando il metodo sopra e ho modificato a mano l'MBR su un editor esadecimale. Non appena ho ricollegato l'HDD, la partizione del braccio si è montata automaticamente! Non lo consiglio però, ci sono stati errori I / O durante il processo e avrei potuto perdere tutto, vedi commento sulla risposta di Rod. Per l'altra partizione non correrò rischi e userò un vecchio HDD e allineerò blocchi alla volta copiando i dati e poi incollandoli in una posizione diversa.


non lo so, ma un'osservazione sembra che tu possa dare lezioni su come funzionano i computer! (e quindi se aiuta a risolvere il problema, acquista un altro disco rigido con i soldi)
barlop

@barlop Grazie! Ma devo già dividere la mia giornata tra il mio lavoro e il college, quindi un secondo lavoro è un no-go in questo momento;) Dovrò sistemare queste partizioni nel modo più duro =)
NothingsImpossible

1
UOMO SONO LE 6 AM E HO PASSATO TUTTA L'ULTIMA NOTTE INTORNO A QUESTO PROBLEMA!
Leonel,

1
Ok, quindi ho il problema opposto: ho un disco da 1 TB formattato usando il contenitore. Quindi è stato formattato usando 4096 byte per indirizzi di settore. Non mi sento a mio agio a modificare l'MBR a mano. E devo usare l'HDD direttamente su SATA (512 byte per settore) Qualche suggerimento?
Leonel,

1
@Leonel Puoi usare Linux fdiskper modificare l'MBR (l'ho appreso più tardi, non c'è bisogno di editor esadecimali :)) Puoi cambiare ogni punto di inizio e dimensione della voce e rivedere le modifiche prima di applicare. Quindi: avviare fdisk, annotare la configurazione corrente (o meglio, eseguire il backup dell'MBR con dd), moltiplicare l'indirizzo iniziale e i valori delle dimensioni per 8 e modificarli. Assicurati di controllare tutto con una calcolatrice e di capire cosa significano i valori. Vedrai che Size = End - Start + 1 e che fdiskmostra le dimensioni in unità di 1000 settori, quindi potrebbe essere necessario attivare la modalità esperto per vedere il valore reale, ecc.
NothingsImpossible

Risposte:


24

I problemi relativi alle dimensioni del settore stanno diventando piuttosto complessi. Fino alla fine del 2009, la stragrande maggioranza dei dischi rigidi utilizzava settori a 512 byte, ed era quello. Alla fine del 2009, i produttori di dischi hanno iniziato a introdurre i cosiddetti dischi Advanced Format (AF), che utilizzano settori a 4096 byte. Questi primi dischi AF (e, AFAIK, tutti i dischi AF oggi) presentano un'interfaccia al computer che mostra ogni settore fisico da 4096 byte come suddiviso in otto settori logici da 512 byte . Questa conversione consente agli strumenti meno recenti, inclusi molti BIOS, creati con ipotesi a 512 byte, di continuare a funzionare. Non so se il tuo disco utilizza AF o meno, ma in entrambi i casi utilizza quasi sicuramente una dimensione del settore logico da 512 byte, il che significa che l'interfaccia al sistema operativo dovrebbe utilizzare i settori da 512 byte.

Complicazioni sono alcuni contenitori di 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 di 4096 byte. Non sono sicuro di quale sia il ragionamento alla base di questa mossa, ma un vantaggio pratico è che i dischi di dimensioni superiori a 2 TB possono essere utilizzati con il vecchio sistema di partizionamento MBR. Uno svantaggio principale è 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 tale contenitore. Si noti che questo problema va ben oltre lo stesso MBR; il tuo disco potrebbe identificare la prima partizione a partire dal settore 2048 (512 byte), ma se il tuo sistema operativo dovesse cercare il settore 2048 (4096 byte),trova l'inizio di quella partizione! Hai riscontrato questo problema. Come tale, il tuo pensiero iniziale che è colpa del contenitore USB è più vicino al segno rispetto al tuo pensiero più recente che la tua scheda madre abbia incasinato. Non ho mai sentito parlare di una scheda madre che traduca le dimensioni del settore in questo modo. (Tuttavia, alcuni dispositivi RAID hardware lo fanno.)

Non conosco un modo per forzare Linux ad adattare la sua idea delle dimensioni del settore, ma se hai abbastanza spazio su disco, fare una copia del disco di basso livello su un altro disco può aiutare. Per 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, diciamo, mount_imagee usalo in questo modo:

./mount_image ~/image.img 2 /mnt

Questo monterà la partizione 2 di image.imga /mnt. Si noti che lo script si basa su fdisk GPT ( gdisk) , che la maggior parte delle distribuzioni include in un pacchetto chiamato gptfdisko gdisk.

A lungo termine, una soluzione migliore è trovare un modo per connettere il disco che non esegua la traduzione di dimensioni settoriali. Una connessione diretta a una nuova scheda madre dovrebbe fare il trucco; oppure puoi probabilmente trovare un recinto 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 usarlo. Mi rendo conto che è probabile che queste soluzioni costino denaro, cosa che dici di non avere, ma forse puoi scambiare il tuo recinto di traduzione con uno che non fa la traduzione.

Un'altra opzione che mi viene in mente è provare a usare una macchina virtuale come VirtualBox. Tale strumento potrebbe assumere una dimensione di settore di 512 byte quando si accede al dispositivo disco, annullando efficacemente 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, il che potrebbe copiare i contenuti con compressione, consentendo all'immagine di adattarsi a meno spazio su disco rispetto a quanto consuma l'originale.


Risposta molto perspicace, ma non proprio quello che stavo cercando .. Ho già provato il metodo della macchina virtuale ma non ho annullato la traduzione. Sono appena arrivato a casa e proverò ad allineare la prima partizione (una più piccola, meno importante) usando dd, e lascerò correre tutta la notte. In caso di successo, proverò a modificare manualmente l'MBR se nessuno mette una risposta.
NothingsImpossible

4
NON provare a modificare il contenuto del disco tramitedd! A meno che tu non sia molto attento e capisca le cose estremamente bene (o sia straordinariamente fortunato), hai maggiori probabilità di rovinare la cosa piuttosto che ripararla. Mi viene in mente che potresti essere in grado di regolare la tabella delle partizioni usandofdisk: Esegui il backup dell'originale e quindi dividi il punto iniziale di ogni partizione per 8 (e imposta i punti finali per terminare appena prima del punto iniziale della partizione seguente). Ciò è possibile solo se i valori del punto iniziale della partizione sono tutti multipli di 8.
Rod Smith

1
Mucca sacra! Grazie per le informazioni. Sto provando a clonare il mio disco fisso Mac / Windows su un SSD da un giorno e sono finalmente riuscito a identificare il problema: l'adattatore Rosewill SATA / IDE a USB che stavo usando per connettere l'SSD stava eseguendo questa "conversione inversa "a settori a 4096 byte! Quindi l'MBR di GPT + Hybrid sull'SSD sembrava assurdo dopo che ci feci un ddclone mentre ero collegato via USB e pensavo che il clone fosse fallito. Ma quando ho collegato l'SSD direttamente alla mia scheda madre al posto del mio vecchio HDD, tutto ha funzionato bene!
Eliot,

1
Non riesco a modificare il mio commento precedente, ma lo strumento Allinea è inutile in questo caso, è solo per scopi di ottimizzazione. Tuttavia, tieni presente che puoi utilizzare TestDisk e dopo una scansione più approfondita, premi P per elencare i file e ripristinare il contenuto del tuo disco (è così che ho recuperato i miei dati, ma non ho trovato alcun modo per correggere il settore byte su questo giorno...).
gaborous

1
Una lettura interessante che conferma il problema e suggerisce la soluzione (emulazione della traduzione di bridge tramite dispositivo di loopback Linux): goughlui.com/2013/10/02/… e questo askubuntu.com/questions/337693/… . E solo come nota aggiuntiva, ho anche provato a modificare forzatamente la dimensione logica in modo che corrisponda alla dimensione fisica, ma l'unità non è stata ancora riconosciuta. Ma formattarlo risolve il montaggio, ma i file sono ovviamente persi, quindi è meglio recuperarli prima tramite il montaggio loopback o testdisk.
gaborous

4

Questo script ha generalizzato la proposta di Rod Smith, quando hai un raid o una criptovaluta. 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

Whoa! Bel lavoro!
NothingsImpossible

3

Un altro modo abbastanza semplice per farlo è usare la funzione di salvataggio di Parted. Ciò richiede tuttavia la creazione di una nuova etichetta del disco, quindi comporta rischi. Parted agisce direttamente sul disco, quindi eseguire i backup secondo necessità prima di eseguire parted. Quindi iniziare:

parted /dev/sdb

parted ti dirà qualcosa in questo senso quando provi a leggere un disco con dimensioni di settore diverse rispetto a quelle con cui è stata creata la tabella delle partizioni:

Error: /dev/sdb: unrecognised disk label                                  

Usa mklabel per creare un nuovo MBR o GPT in base a quello che hai usato in precedenza

(parted) mklabel
New disk label type? mbr

Quindi esegui il salvataggio per trovare la tua vecchia partizione

(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

Ripeti il ​​processo di salvataggio se hai più partizioni. Ora hai finito.


1
Questo ha funzionato perfettamente per me per convertire la mia tabella delle partizioni da mbr a gpt. In questo modo in modo da poter espandere un disco clonato da 2 TB a 4 TB. Un po 'nervoso lasciando la mia partizione sospesa lì, ma questo è molto più veloce di altri metodi.
Oregon Trail

3

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 è disattivata di un fattore 8 e
  2. la tabella delle partizioni MBR non può gestire> 2 TB quando la dimensione del settore è 512.

Soluzione: riscrivere la tabella delle partizioni in un GPT, convertendo i valori in settori a 512 byte.

Nel mio caso la partizione è iniziata con un offset di 1 MB e si è conclusa (~ 856kB) prima della fine del disco. Ciò è positivo perché ha consentito l'MBR + GPT (17408 byte) prima della partizione e del backup GPT (16896 byte) alla fine del disco.

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

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

Ho usato gdisk per cancellare la prima partizione. Se vuoi, puoi fare come ho fatto io e cambiare il valore di allineamento su 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 delle dimensioni del settore non influisce sul file system, su LVM o su LUKS.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.