Re : Re: Re: Problème de montage d'un disque dur "ZFS"
Le mercredi 7 juillet 2021 à 09:29, didier gaumet <didier.gaumet@gmail.com> a écrit :
> je me demanderais si la table GPT est véritablement corrompue ou si le
> parted de Debian la désigne comme telle: Freenas/Truenas c'est du BSD,
> je pense que le monde BSD s'est mis à GPT plus tard que le monde Linux
> et qu'il traîne potentiellement avec lui des éléments anciens (slices,
> couche de compatibilité MBR dans le GPT).
Je connais un peu GPT pour m'être battu avec il y a des années en
installant des dual boot sur les premiers mac à processeurs intel.
Pour ce qui concerne la couche de compatibilité MBR le premier secteur
est sensé contenir une table de partition MBR factice avec une unique
partition de type GPT occupant tout le disque afin qu'un outil de
partitionnement n'implémentant pas GPT ne le considère pas comme vierge.
Cette table était "bidouillée" par bootcamp sur les mac pour permettre à
windows (qui n'implémentait pas GPT) de trouver ses partitions...
GPT est un système robuste avec checksum et backup et de mémoire il me
semble que la moindre modification "sauvage" du mbr faussait le
checksum et invalidait ainsi la table GPT principale. Il est possible
que linux n'en tienne pas compte quand il s'agit du disque de démarrage
et qu'il soit plus exigeant pour un disque secondaire...
Si j'ai bien compris ce disque a été repartitionné après son utilisation
avec freenas et tu cherches juste à pouvoir monter tes partition pour
récupérer tes données.
D'après ce que j'ai vu dans tes sorties de parted et fdisk, la table
"backup" semble correcte hormis le type de la dernière partition qui
est incohérent avec le système de fichier ext4 détecté par parted.
En reprenant la sortie de fdisk -l dans ton premier message :
Unités : secteur de 1 × 512 = 512 octets
...
Périphérique Début Fin Secteurs Taille Type
/dev/sda1 34 78125034 78125001 37,3G Données de base Microsoft
/dev/sda2 78125035 85937535 7812501 3,7G Partition d'échange Linux
/dev/sda3 85938176 585936895 499998720 238,4G Système de fichiers Linux
/dev/sda4 585936896 1347655679 761718784 363,2G Système de fichiers Linux
/dev/sda5 1347655680 1973372927 625717248 298,4G Système de fichiers Linux
/dev/sda6 1973374336 3906948479 1933574144 922G Données de base Microsoft
Pour sda1 parted n'a pas détecté de système de fichier donc "c'est mort".
sda2 je pense qu'on s'en moque...
Pour sda3 :
# losetup --offset $((85938176*512)) --sizelimit $((499998720*512)) /dev/loop0 /dev/sda
# e2fsck -nf /dev/loop0
devrait donner quelque chose du genre :
e2fsck 1.44.5 (15-Dec-2018)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
SaveNico : xxx/xxxxxxxx fichiers (x.x% non contigus), xxx/xxxxxxxx blocs
Jusque-là il n'y a aucun risque, losetup ne touche pas à ton disque (il se
contente d'en "mapper" une portion dans /dev) et e2fsck non plus avec
l'option -n.
Si le volume est propre il n'y a plus qu'à le monter :
# mkdir /mnt/SaveNico
# mount /dev/loop0 /mnt/SaveNico
Une fois les fichiers récupérés :
# umount /dev/loop0
# rmdir /mnt/SaveNico
# losetup -d /dev/loop0
Pour sda4 utiliser :
--offset $((585936896*512)) --sizelimit $((761718784*512))
Et ainsi de suite en prenant à chaque fois le secteur de "Début" pour
offset et le nombre "Secteurs" pour sizelimit.
Tu peux en faire plusieurs en même temps en utilisant /dev/loop1 etc.
Cordialement
Hugues
Reply to: