Je savais déjà ce que je devais faire pour résoudre ce problème; Je ne savais pas comment le faire. J'espérais qu'il y aurait un outil prêt à l'emploi pour le faire automatiquement - mais je n'en ai trouvé aucun. J'accepte la réponse de Rod parce que, même si elle ne résout pas directement mon problème, cela donne un très bon historique du problème de la taille du secteur et me permet de croire que le problème est vraiment l'alignement et le traitement des partitions. Pour ceux qui abordent cette question avec le même problème, lisez-la attentivement, y compris les commentaires, avant de faire quoi que ce soit.
J'avais un ordinateur et j'avais besoin de plus d'espace. J'ai acheté un nouveau disque dur de 500 Go et un boîtier USB. Bientôt, j'ai remarqué que si je partitionnais le disque sur le boîtier et que je le déplaçais sur l'ordinateur, il ne reconnaîtrait pas les partitions (et inversement). J'ai supposé que c'était un problème avec le boîtier et je ne m'en suis pas inquiété.
Un jour merveilleux, 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'utilise comme serveur de fichiers et ce disque de 500 Go est maintenant rempli de données que je ne peux pas me permettre de perdre. Je suis cassé maintenant et ne peux pas me permettre un nouvel ordinateur, donc mon seul espoir était le boîtier USB "défectueux".
Armé de plusieurs distributions Linux, d'un ordinateur portable, de VirtualBox et de l'enceinte, j'ai effectué une analyse judiciaire sur la question. dmesg a signalé que la taille de la partition était au-delà de la fin du disque. J'ai donc parcouru les feuilles de données du disque dur, calculé le nombre de secteurs à partir de zéro, testé manuellement les limites du lecteur avec jj, et tout semblait aller pour le mieux, jusqu'à ce que je lance fdisk et qu'il dise:
Note: Sector size is 4096 (not 512).
C'est modeste de fdisk. Cette "note" était la racine de toutes les questions. Après quelques modifications 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é de secteurs de 4 096 octets au système d'exploitation. Le système d'exploitation a donc créé le MBR avec joie 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.
Alors, comment puis-je corriger les adresses dans le MBR afin qu'elles soient valides sur une taille de secteur de 4096 octets, mis à part la modification manuelle du MBR sur un éditeur hexadécimal, et
Les partitions ne sont pas alignées pour des 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 disque de rechange) ou devrai-je créer un outil qui "décale" les données sur le côté, un petit morceau à la fois? Les partitions sont ext3.
Merci!
J'ai trouvé qu'il y avait un moyen intelligent d'utiliser dd pour déplacer la partition sur 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 maintenant mais le ferai quand j'ai du temps.
J'ai donc réussi à aligner la partition en utilisant la méthode ci-dessus et à éditer manuellement le MBR sur un éditeur hexadécimal. Dès que j'ai rebranché le disque dur, la partition de la flèche est automatiquement montée! Je ne le recommande cependant pas, il y a eu des erreurs d'E/S au cours du 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, j’utiliserai un ancien disque dur et alignerai des morceaux à la fois en copiant les données, puis en les collant à un autre emplacement.
Les problèmes de taille de secteur deviennent de plus en plus 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 ditsAdvanced Format(AF), qui utilisent des secteurs de 4 096 octets. Ces premiers disques AF (et, autant que je sache, tous les disques AF actuels) présentent une interface avec l'ordinateur qui montre que chaque secteur de 4096 octetsphysiqueest divisé en huit. octetlogiquesecteurs. Cette conversion permet aux anciens outils, y compris de nombreux BIOS, 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 vers le système d'exploitation doit utiliser des secteurs de 512 octets.
Certains boîtiers de disques USB compliquent les choses. Certains de ces boîtiers font l'inverse de ce que fait AF: ils prennent huit secteurs de disque et les regroupent dans un nouveau secteur de 4 096 octets. Je ne suis pas sûr du raisonnement derrière ce changement, mais un avantage pratique réside dans le fait que les disques de plus de 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 ne faisant 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 (512 octets) 2048, mais si votre système d'exploitation cherchait le secteur (4096 octets) 2048, ilpastrouve 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 a tout gâché. J'aijamaisentendu parler d'une carte mère traduisant la taille du secteur de cette manière. (Cependant, certains périphériques RAID matériels le font.)
Je ne connais aucun moyen de forcer Linux à ajuster sa taille du secteur, mais si vous disposez de suffisamment d'espace disque, 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 de /dev/sdb
(le 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_image
et utilisez-le comme ceci:
./mount_image ~/image.img 2 /mnt
Cela montera la partition 2 de image.img
sur /mnt
. Notez que le script repose sur GPT fdisk (gdisk
) , que la plupart des distributions incluent dans un package appelé gptfdisk
ou gdisk
.
À long terme, une meilleure solution consiste à trouver un moyen de connecter le disque qui ne fera pas la traduction à 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. Si votre boîtier dispose d'un port eSATA, vous pouvez essayer de l'utiliser. Je me rends compte que toutes ces solutions sont susceptibles de coûter de l’argent, ce que vous dites ne pas avoir, mais vous pouvez peut-être échanger votre pièce jointe de traduction par une pièce jointe contre une pièce qui ne fait pas la traduction.
Une autre option qui me vient à l’esprit est d’essayer d’utiliser une machine virtuelle telle que VirtualBox. Un tel outil peut prendre une taille de secteur de 512 octets lors de l’accès au périphérique de disque, annulant ainsi la traduction; ou vous pouvez peut-être copier le contenu brut du disque (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'utilisé par défaut.
Ce script a généralisé la proposition de Rod Smith lorsque vous avez un raid ou une crypto. Aucune garantie. N'hésitez pas à l'améliorer! (Mise à 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 faire cela consiste à utiliser la fonction de sauvetage de parted. Cela nécessite toutefois de créer une nouvelle étiquette de disque, ce qui implique des risques. Parted agit directement sur le disque, alors effectuez les sauvegardes nécessaires avant de lancer 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 déjà utilisé
(parted) mklabel
New disk label type? mbr
Puis lancez rescue pour retrouver 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 secours 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:
Solution: Réécrivez la table de partition en un GPT, en convertissant les valeurs pour utiliser des secteurs de 512 octets.
Dans mon cas, la partition a démarré avec un décalage de 1 Mo et s'est terminée (~ 856 Ko) avant la fin du disque. C'est bien parce qu'alors cela a permis au MBR + GPT (17408 octets) avant la partition et au GPT de sauvegarde (16896 octets) à la fin du disque.
J'ai créé des images des deux régions au cas où (avec 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 ce que j'ai fait 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, le changement de taille de secteur n'affecte pas le système de fichiers, LVM ou LUKS.