Comment corriger le secteur MBR de 512 octets sur un disque de secteur de 4096 octets?

23

Mise à jour finale:

Je savais déjà ce que je devais faire pour résoudre ce problème; Je ne savais tout simplement pas comment faire. J'espérais qu'il y aurait un outil prêt à l'emploi pour le faire automatiquement - mais je n'en ai pas trouvé. J'accepte la réponse de Rod parce que même si je ne résout pas directement mon problème, cela donne un très bon contexte sur le problème de la taille du secteur et m'a donné la certitude que le problème était vraiment l'alignement et la résolution des partitions. Pour ceux qui viennent à cette question ayant le même problème, lisez-le attentivement et attentivement, y compris les commentaires, avant de faire quoi que ce soit.


Au début

J'avais un ordinateur et j'avais besoin de plus d'espace, j'ai acheté un nouveau disque de 500 Go et un boîtier USB. Bientôt, j'ai remarqué que si je partitionnais le lecteur sur le boîtier et le déplaçais vers l'ordinateur, il ne reconnaîtrait pas les partitions (et vice-versa). J'ai supposé que c'était un problème avec le boîtier et je ne m'en suis pas inquiété.

Ensuite, la tragédie

Une merveilleuse journée, mon ordinateur a décidé de ne plus s'allumer. Il s'avère que la carte mère (sans marque, juste un gros MADE IN CHINA imprimé dessus) est morte. Je l'ai utilisé comme serveur de fichiers et ce disque de 500 Go est maintenant plein de données que je ne peux pas me permettre de perdre. Je suis en panne maintenant et je ne peux pas me permettre un nouvel ordinateur, donc mon seul espoir était le boîtier USB "défectueux".

L'enquête

Armé de plusieurs distributions Linux, d'un ordinateur portable, de VirtualBox et du boîtier, j'ai fait une analyse médico-légale sur la question. dmesg a signalé que la taille de la partition dépassait la fin du lecteur. J'ai donc parcouru les fiches techniques des disques durs, calculé le nombre de secteurs à partir de zéro, testé manuellement les limites des disques avec dd, et tout semblait OK, jusqu'à ce que je déclenche fdisk et qu'il soit dit:

    Note: Sector size is 4096 (not 512).

Quelle modestie de fdisk. Cette "note" était à l'origine de tous les problèmes. Après quelques manipulations supplémentaires, ces conclusions ont été tirées:

  • Le boîtier USB n'est pas défectueux.

  • Le contrôleur SATA sur la carte mère maintenant morte est celui qui était "bizarre", au moins. Il n'a pas signalé les secteurs de 4096 octets au système d'exploitation, donc le système d'exploitation a heureusement créé le MBR en utilisant des adresses de secteur de 512 octets.

  • Maintenant, lorsque j'essaie d'accéder à la partition, le système d'exploitation essaie d'utiliser les adresses basées sur 512 octets sur un lecteur de secteur de 4096 octets, et bien sûr, cela ne fonctionnera pas.

La question

  • Alors, comment puis-je corriger les adresses dans le MBR afin qu'elles soient valides sur une taille de secteur de 4096 octets, à part la modification manuelle du MBR sur un éditeur hexadécimal, et

  • Les partitions ne sont pas alignées pour les secteurs de 4096 octets. Il existe un outil disponible pour les aligner en dehors de la copie dans et hors d'un autre lecteur? (Je n'ai pas de disques de rechange), ou devrai-je créer un outil qui "décale" les données sur le côté un peu à la fois? Les partitions sont ext3.

Merci!

Mise à jour:

J'ai trouvé qu'il existe un moyen intelligent d'utiliser dd pour déplacer la partition en place dans cette question: Comment déplacer une partition sous GNU / Linux? Mais je ne sais pas si cela fonctionnera sur une tranche de secteur, cependant. Je ne peux pas le tester pour le moment mais le ferai quand j'aurai du temps.

Mise à jour 2:

J'ai donc réussi à aligner la partition en utilisant la méthode ci-dessus et à modifier manuellement le MBR sur un éditeur hexadécimal. Dès que j'ai rebranché le disque dur, la partition de la flèche est montée automatiquement! Je ne le recommande pas cependant, il y a eu des erreurs d'E / S pendant le processus et j'aurais pu tout perdre, voir le commentaire sur la réponse de Rod. Pour l'autre partition, je ne prendrai pas de risques et utiliserai un ancien disque dur et alignerai des morceaux à la fois en copiant les données puis en les collant dans une position différente.

Rien n'est impossible
la source
Je ne sais pas, mais une remarque - on dirait que vous pourriez donner des leçons sur le fonctionnement des ordinateurs! (puis si cela aide à résoudre le problème, achetez un autre disque dur avec de l'argent)
barlop
@barlop Merci! Mais je dois déjà partager ma journée entre mon travail et le collège, donc un deuxième travail est à proscrire en ce moment;) Je vais devoir réparer ces partitions à la dure =)
NothingsImpossible
1
HOMME IL EST 6 H ET J'AI PASSÉ TOUTE LA DERNIÈRE NUIT AUTOUR DE CE PROBLÈME!
Leonel
1
Ok, j'ai donc le problème inverse: j'ai un disque de 1 To formaté en utilisant le boîtier. Il a donc été formaté en utilisant 4096 octets par adresses de secteur. Je ne suis pas à l'aise pour éditer le MBR à la main. Et je dois utiliser le disque dur directement sur SATA (512 octets par secteur) Des suggestions?
Leonel
1
@Leonel Vous pouvez utiliser Linux fdiskpour modifier le MBR (j'ai appris cela plus tard, pas besoin d'éditeurs hexadécimaux :)) Vous pouvez changer chaque point de départ et taille d'entrée, et revoir les changements avant de postuler. Donc: démarrez fdisk, notez la configuration actuelle (ou mieux, sauvegardez le MBR avec dd), multipliez l'adresse de début et les valeurs de taille par 8 et modifiez-les. Assurez-vous de tout vérifier avec une calculatrice et de comprendre ce que signifient les valeurs. Vous verrez que Size = End - Start + 1, et cela fdiskmontre la taille en unité de 1000 secteurs, vous devrez donc peut-être activer le mode expert pour voir la valeur réelle, etc.
NothingsImpossible

Réponses:

24

Les problèmes de taille sectorielle deviennent assez complexes. Jusqu'à la fin de 2009, la grande majorité des disques durs utilisaient des secteurs de 512 octets, et c'était tout. Fin 2009, les fabricants de disques ont commencé à introduire des disques AF ( Advanced Format ), qui utilisent des secteurs de 4096 octets. Ces premiers disques AF (et, AFAIK, tous les disques AF aujourd'hui) présentent une interface avec l'ordinateur qui montre que chaque secteur physique de 4096 octets est divisé en huit secteurs logiques de 512 octets . Cette conversion permet aux outils plus anciens, y compris de nombreux BIOS, qui ont été construits avec des hypothèses de 512 octets, de continuer à fonctionner. Je ne sais pas si votre disque utilise AF ou non, mais dans les deux cas, il utilise presque certainement une taille de secteur logique de 512 octets, ce qui signifie que l'interface avec le système d'exploitation devrait utiliser des secteurs de 512 octets.

Pour compliquer les choses, certains boîtiers de disques USB. Certains de ces boîtiers font l'inverse de ce que fait l'AF: ils prennent huit secteurs de disque et les regroupent en un nouveau secteur de 4096 octets. Je ne sais pas quel est le raisonnement derrière cette décision, mais un avantage pratique est que les disques plus grands que 2 To peuvent être utilisés avec l'ancien système de partitionnement MBR. Un inconvénient majeur est qu'un disque partitionné dans l'un de ces boîtiers ne peut pas être utilisé directement ou dans un boîtier qui ne fait pas ce type de traduction. De même, un disque préparé sans cette traduction ne peut pas être utilisé lorsqu'il est transféré dans une telle enceinte. Notez que ce problème va bien au-delà du MBR lui-même; votre disque peut identifier la première partition comme commençant sur le secteur 2048 (512 octets), mais si votre système d'exploitation devait chercher dans le secteur 2048 (4096 octets),trouver le début de cette partition! Vous avez rencontré ce problème. En tant que tel, votre pensée initiale que c'est la faute du boîtier USB est plus proche de la marque que votre pensée plus récente que votre carte mère l'a gâché. Je n'ai jamais entendu parler d'une carte mère traduisant la taille du secteur de cette façon. (Certains périphériques RAID matériels le font cependant.)

Je ne connais pas de moyen de forcer Linux à ajuster son idée de la taille du secteur, mais si vous avez suffisamment d'espace disque, faire une copie de disque de bas niveau sur un autre disque peut aider. Par exemple:

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

Cela copiera votre disque /dev/sdb(du disque USB; ajustez si nécessaire) dans le fichier ~/image.img. Vous pouvez ensuite utiliser le script suivant pour monter les partitions de l'image:

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

Enregistrez le script sous, par exemple, mount_imageet utilisez-le comme ceci:

./mount_image ~/image.img 2 /mnt

Cela montera la partition 2 de image.imgto /mnt. Notez que le script repose sur GPT fdisk ( gdisk) , que la plupart des distributions incluent dans un package appelé gptfdiskou gdisk.

À long terme, une meilleure solution consiste à trouver un moyen de connecter le disque qui ne fera pas la traduction de la taille du secteur. Une connexion directe à une nouvelle carte mère devrait faire l'affaire; ou vous pouvez probablement trouver un boîtier externe qui ne fait pas la traduction. En fait, certains boîtiers effectuent la traduction sur les ports USB mais pas sur les ports eSATA, donc si votre boîtier dispose d'un port eSATA, vous pouvez essayer de l'utiliser. Je me rends compte que ces solutions sont toutes susceptibles de coûter de l'argent, ce que vous dites que vous n'avez pas, mais vous pouvez peut-être échanger votre boîtier de traduction contre un qui ne fait pas la traduction.

Une autre option qui me vient à l'esprit est d'essayer d'utiliser une machine virtuelle comme VirtualBox. Un tel outil peut supposer une taille de secteur de 512 octets lors de l'accès au périphérique de disque, annulant ainsi la traduction; ou vous pourriez être en mesure de copier le contenu du disque brut (comme dans dd if=/dev/sdc of=/dev/sdb) dans la machine virtuelle, ce qui pourrait copier le contenu avec compression, permettant ainsi à l'image de tenir sur moins d'espace disque que l'original ne consomme.

Rod Smith
la source
Réponse très perspicace, mais pas tout à fait ce que je cherchais .. J'ai déjà essayé la méthode de la machine virtuelle mais elle n'a pas annulé la traduction. Je viens d'arriver à la maison et j'essaierai d'aligner la première partition (une plus petite et moins importante) à l'aide de dd et de la laisser fonctionner pendant la nuit. En cas de succès, j'essaierai de modifier le MBR à la main si personne ne répond.
NothingsImpossible
4
N'essayez PAS de modifier le contenu du disque viadd! À moins que vous soyez très prudent et que vous compreniez extrêmement bien leschoses(ouque vous ayez une chance extraordinaire ), vous êtes plus susceptible de jeter la chose que de la réparer. Il me semble que vous pourriez être en mesure d'ajuster la table de partition en utilisantfdisk: Sauvegardez l'original, puis divisez le point de départ de chaque partition par 8 (et définissez les points de fin pour qu'ils se terminent juste avant le point de départ de la partition suivante). Cela n'a de chance que si les valeurs de point de départ de la partition sont toutes des multiples de 8.
Rod Smith
1
Sainte vache! Merci pour l'info. Cela fait maintenant un jour que j'essaie de cloner mon disque dur Mac / Windows sur un SSD et j'ai finalement pu identifier le problème: l'adaptateur Rosewill SATA / IDE vers USB que j'utilisais pour connecter le SSD effectuait cette "conversion inverse "aux secteurs de 4096 octets! Donc, le MBT hybride GPT + sur le SSD ressemblait à un non-sens après avoir fait un ddclone dessus alors qu'il était connecté via USB, et je pensais que le clone avait échoué. Mais lorsque j'ai connecté le SSD directement à ma carte mère à la place de mon ancien disque dur, tout a bien fonctionné!
Eliot
1
Impossible de modifier mon commentaire précédent, mais l'outil Aligner est inutile dans ce cas, c'est juste à des fins d'optimisation. Cependant, notez que vous pouvez utiliser TestDisk et après une analyse plus approfondie, appuyez sur P pour répertorier les fichiers et récupérer le contenu de votre disque (c'est ainsi que j'ai récupéré mes données, mais je n'ai trouvé aucun moyen de corriger le secteur d'octets pour ce jour...).
génial
1
Une lecture intéressante qui confirme le problème et fait allusion à la solution (émulation de la traduction du pont via le périphérique de bouclage Linux): goughlui.com/2013/10/02/… et ce askubuntu.com/questions/337693/… . Et juste comme une note supplémentaire, j'ai également essayé de modifier de force la taille logique pour qu'elle corresponde à la taille physique, mais le lecteur n'était toujours pas reconnu. Mais le formatage corrige le montage, mais les fichiers sont bien sûr perdus, il vaut donc mieux les récupérer avant via un montage en boucle ou un disque de test.
génial
4

Ce script a généralisé la proposition de Rod Smith, lorsque vous avez un raid ou un crypto. Aucune garantie. N'hésitez pas à l'améliorer! (Mis à jour avec les dernières découvertes sur 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
user302662
la source
Whoa! Bon travail!
NothingsImpossible
3

Une autre façon assez simple de le faire est d'utiliser la fonction de sauvetage de parted. Cela nécessite toutefois que vous créiez une nouvelle étiquette de disque, ce qui implique des risques. Parted agit directement sur le disque, effectuez les sauvegardes nécessaires avant d'exécuter parted. Puis commencez:

parted /dev/sdb

parted vous dira quelque chose dans ce sens lorsque vous essayez de lire un disque avec une taille de secteur différente de celle avec laquelle la table de partition a été créée:

Error: /dev/sdb: unrecognised disk label                                  

Utilisez mklabel pour créer un nouveau MBR ou GPT en fonction de ce que vous avez utilisé précédemment

(parted) mklabel
New disk label type? mbr

Exécutez ensuite le sauvetage pour trouver votre ancienne partition

(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

Répétez le processus de sauvetage si vous avez plus de partitions. Vous avez maintenant terminé.

Johan Ehnberg
la source
1
Cela a parfaitement fonctionné pour moi pour convertir ma table de partition de mbr en gpt. Faire cela afin que je puisse étendre un disque de 2 To cloné à 4 To. Un peu nerveux laissant ma partition accrochée là mais c'est tellement plus rapide que les autres méthodes.
OregonTrail
3

J'ai eu ce problème lorsque j'ai retiré un disque de 4 To d'un boîtier externe WD My Book. Le problème est:

  1. la table de partition MBR est décalée d'un facteur 8 et
  2. la table de partition MBR ne peut pas gérer> 2 To lorsque la taille du secteur est 512.

Solution: réécrivez la table de partition en GPT, en convertissant les valeurs pour utiliser des secteurs de 512 octets.

Dans mon cas, la partition a commencé sur un décalage de 1 Mo et s'est terminée (~ 856 Ko) avant la fin du disque. C'est bien car cela permettait alors le MBR + GPT (17408 octets) avant la partition et le GPT de sauvegarde (16896 octets) à la fin du disque.

J'ai fait des images des deux régions au cas où (en utilisant dd).

J'ai noté la sortie de fdisk -l /dev/sde.

J'ai utilisé gdisk pour supprimer la première partition. Si vous le souhaitez, vous pouvez faire comme moi et modifier la valeur d'alignement sur 8 (4096) pour utiliser autant d'espace que possible. Ensuite, j'ai créé une nouvelle partition avec le début à 2048 et la fin à la fin du disque. Je développerai le système de fichiers plus tard.

Heureusement, la modification de la taille du secteur n'affecte pas le système de fichiers, LVM ou LUKS.

Duane
la source