Les questions de taille de secteur deviennent assez complexes. Jusqu'à fin 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 ce qu'on appelle le format avancé (AF) qui utilisent des secteurs de 4096 octets. Ces premiers disques AF (et, autant que je sache, tous les disques AF d'aujourd'hui) présentent une interface avec l'ordinateur qui affiche chaque physique de 4 096 octets. secteur comme étant divisé en huit logiques de 512 octets secteurs. Cette conversion permet aux outils plus anciens, 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 avec le système d'exploitation doit 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 AF :ils prennent huit secteurs de disque et les regroupent dans 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 des 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 qui ne fait pas ce type de traduction. De même, un disque préparé sans cette traduction ne peut ê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 cherchait le secteur 2048 (4096 octets), ce ne serait pas 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 réalité que votre pensée plus récente selon laquelle 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 manière. (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 à partir de /dev/sdb (le disque USB ; ajuster si nécessaire) au 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, disons, mount_image et utilisez-le comme ceci :
./mount_image ~/image.img 2 /mnt
Cela montera la partition 2 de image.img à /mnt . Notez que le script s'appuie 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 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 ne pas avoir, mais vous pouvez peut-être échanger votre boîtier de traduction contre un autre 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 pourrez peut-être copier le contenu du disque brut (comme dans dd if=/dev/sdc of=/dev/sdb ) dans la machine virtuelle, qui peut copier le contenu avec compression, permettant ainsi à l'image de tenir sur moins d'espace disque que l'original n'en consomme.
Ce script a généralisé la proposition de Rod Smith, lorsque vous avez un raid ou une crypto. Pas de 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
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 :
- la table de partition MBR est décalée d'un facteur 8 et
- la table de partition MBR ne peut pas gérer> 2 To lorsque la taille du secteur est de 512.
Solution : Réécrivez la table de partition dans un 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 juste 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 changer la valeur d'alignement à 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.