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.

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.

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

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é.

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.