10.12 Sierra Disque dur externe crypté reformaté
- Créateur du sujet Mc kintosh
- Date de début
M
Membre supprimé 1060554
Invité
Alors voici un moment de vérité -->
Passe déjà la commande :
- si le bloc n°40 = bloc 0 de la partition > qui est aussi le super-bloc du système de fichiers FAT-32 de la partition EFI --> n'a pas été "zéroisé" par le logiciel Linux > alors la redescription valide du conteneur de l'ancienne partition au bloc près => devrait permettre la reprise en charge du système de fichiers par le kernel
- si le bloc n°40 (et les suivants) a été "zéroisé" --> alors une partition de type EFI va bien se trouver recréée > mais sans système de fichiers FAT-32 générateur d'un volume EFI. On n'aura donc affaire qu'à un conteneur de partition vide.
Passe déjà la commande :
Bloc de code:
sudo gpt show disk5- et poste le tableau des blocs --> histoire de vérifier l'existence d'une partition définie par le nouveau descripteur.
Bloc de code:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 5860123491
5860533131 32 Sec GPT table
5860533163 1 Sec GPT header
M
Membre supprimé 1060554
Invité
Cette ligne -->
Passe la commande :
On va voir comment le kernel prend en charge cette partition.
Bloc de code:
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B- montre que le nouveau descripteur a bien agi : une partition se trouve recréée au 1er rang sur les blocs.
Passe la commande :
Bloc de code:
diskutil list- et poste le tableau des disques
On va voir comment le kernel prend en charge cette partition.
Bloc de code:
/dev/disk5 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk5
1: EFI 209.7 MB disk5s1
M
Membre supprimé 1060554
Invité
On voit que la nouvelle partition est prise en charge au rang n°1 > comme de type EFI > avec une taille canonique de 209,7 Mo > et l'index d'appareil disk5s1.
Mais ! --> aucun volume nommé EFI (comme le type de partition) > ne se trouve chargé par le kernel sur la partition. Ce qui laisse suspecter que la "zéroïsation" aurait effacé le système de fichiers FAT-32 générateur du volume EFI.
Passe la commande :
Poste ce tableau --> il montrera s'il existe un système de fichiers FAT-32 dans le conteneur de la partition ou aucun...
Mais ! --> aucun volume nommé EFI (comme le type de partition) > ne se trouve chargé par le kernel sur la partition. Ce qui laisse suspecter que la "zéroïsation" aurait effacé le système de fichiers FAT-32 générateur du volume EFI.
Passe la commande :
Bloc de code:
diskutil info disk5s1- la commande affiche un tableau d'informations sur la partition
Poste ce tableau --> il montrera s'il existe un système de fichiers FAT-32 dans le conteneur de la partition ou aucun...
Bloc de code:
Device Identifier: disk5s1
Device Node: /dev/disk5s1
Whole: No
Part of Whole: disk5
Volume Name: Not applicable (no file system)
Mounted: Not applicable (no file system)
File System: None
Partition Type: EFI
OS Can Be Installed: No
Media Type: Generic
Protocol: USB
SMART Status: Not Supported
Disk / Partition UUID: 1DDFC3B0-E382-7E4A-84B9-8DB041FBFCEB
Disk Size: 209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units)
Device Block Size: 512 Bytes
Read-Only Media: No
Read-Only Volume: Not applicable (no file system)
Device Location: External
Removable Media: Fixed
M
Membre supprimé 1060554
Invité
Voici la réponse -->
Conclusion (provisoire) : si environ 500 Mo de blocs ont eu le temps de se trouver "zéroïsés" sous Linux > l'opération n'ayant pas touché la table GPT > l'ensemble de l'extension de la partition EFI (209,7 Mo) a été "zéroïsé". Mais (malheureusement) la "zéroïsation" a débordé sur la partition suivante = la 1ère des grandes partitions de stockage > dont le système de fichiers a forcément été lui aussi effacé.
On continue sur la partition de rang n°2 ?
Bloc de code:
File System: None- aucun système de fichiers présent dans la partition
Conclusion (provisoire) : si environ 500 Mo de blocs ont eu le temps de se trouver "zéroïsés" sous Linux > l'opération n'ayant pas touché la table GPT > l'ensemble de l'extension de la partition EFI (209,7 Mo) a été "zéroïsé". Mais (malheureusement) la "zéroïsation" a débordé sur la partition suivante = la 1ère des grandes partitions de stockage > dont le système de fichiers a forcément été lui aussi effacé.
On continue sur la partition de rang n°2 ?
Je bois tes paroles, on continue. J'ai une sauvegarde de DiskDrill avec tout ce qu'il avait trouvé dans le pire des cas. Je pourrais reprendre là où il s'était arrêté.
M
Membre supprimé 1060554
Invité
Oui par sécurité en cas d'effraction dans la maison, ici c'est un peu la folie.
M
Membre supprimé 1060554
Invité
Alors on est obligés de repasser en mode "théorique" -->
On débouche donc du théorique sur le pratique comme conséquence logique nécessaire (càd. démontrée).
Passe les commandes :
Poste l'affichage retourné.
- un volume de stockage protégé par un chiffrement dans l'environnement Sierra > implique la génération d'un système de stockage CoreStorage sur la partition. Ce qui importe de savoir ici (sans entrer dans des descriptions de détails du CoreStorage) est que : a) le type de la partition impliquée est converti de "Apple_HFS" => à "Apple_CoreStorage" (important pour la recréation d'un descripteur valide de partition) > b) le dispositif CoreStorage de la partition principale requiert nécessairement un « booter » : un logiciel de prédémarrage recelé dans un volume intitulé Boot OS X d'une petite partition subalterne d'exactement 134 Mo > dont le type est "Apple_Boot".
- la coutume est que la première partition principale (n°2) après la partition EFI (n°1) colle au bloc près à cette partition. Donc on sait que le bloc 0 de la partition de stockage n°2 est le bloc n°409640 : c'est le super-bloc du système de fichiers primaire (jhfs+) de cette partition. On sait qu'une partition « booter » de 134 Mo est requise - sans aucun bloc de séparation - en-dessous de la partition de type "Apple_Storage". Dans le tableau primaire de la table GPT > cette partition « booter » était décrite avec le faux rang n°1 ainsi -->
Bloc de code:
2725505336 262144 1 GPT part - 48465300-0000-11AA-AA11-00306543ECAC- l'extension de 262144 blocs fait exactement 134,21 Mo. On a donc bien affaire là à la partition « booter » située exactement en-dessous de la partition CoreStorage. On sait donc nécessairement que la partition CoreStorage s'arrête au bloc juste avant le bloc n°2725505336 de départ de la partition « booter » > càd. le bloc n°2725505335. On connaît donc le bloc 0 de la partition à recréer > son extension de blocs au bloc près > son type CoreStorage et son rang n°2 qui est vacant.
On débouche donc du théorique sur le pratique comme conséquence logique nécessaire (càd. démontrée).
Passe les commandes :
Bloc de code:
diskutil umountDisk force disk5
sudo gpt add -b 409600 -s 2725095736 -t 53746F72-6167-11AA-AA11-00306543ECAC -i 2 /dev/disk5- la commande crée un descripteur de partition de rang n°2 > avec le bloc n° 409600 en bloc 0 > une extension de 2725095736 blocs = 1395.24 Go > et un type "Apple_CoreStorage (déterminé par son UUID de type)
Poste l'affichage retourné.
Bloc de code:
gpt add: /dev/disk5: error: no space available on deviceMerci de ton aide.
M
Membre supprimé 1060554
Invité
Il y a eu une erreur concernant le calcul de taille de la nouvelle partition. Je reverrai mes calculs. À plus tard.
Je te remercie infiniment. Je te cacherais pas que je suis complètement dépassé... J'espère avoir l'occasion d'acheter si je récupère tout un graveur BluRay pour enregistrer sur disque physique les 300 gigas de photos et films de famille.
M
Membre supprimé 1060554
Invité
Le disque à une taille totale de 5860533164 blocs = 3000.59 Go. J'ai demandé la création d'une partition n°2 démarrant au bloc n°409600 > pour une extension de 2725095736 blocs = 1395.24 Go. Cette taille est parfaitement supportée et laisse 3135437428 blocs libres = 1605,34 Go.
Le déni :
Préviens quand tu es de nouveau disponible.
Le déni :
Bloc de code:
gpt add: /dev/disk5: error: no space available on device- est donc dénué de fondement. Il faudra que tu redémarres une fois pour remettre les choses en place (il y a eu énormément d'écritures à la table)
Préviens quand tu es de nouveau disponible.
C'est bon je viens de rédémarrer
J'ai viré une clé usb donc on est maintenant sur Disk4
J'ai viré une clé usb donc on est maintenant sur Disk4
Bloc de code:
/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk4
1: EFI 209.7 MB disk4s1
M
Membre supprimé 1060554
Invité
Alors passe les commandes (auxquelle je n'ai rien changé - sinon l'index du disque-cible) :
Bloc de code:
diskutil umountDisk force disk4
sudo gpt add -b 409600 -s 2725095736 -t 53746F72-6167-11AA-AA11-00306543ECAC -i 2 /dev/disk4- poste le retour de la 2è.
Sujets similaires
10.11 El Capitan
Le processus S.O.S a échoué [...] une erreur interne s'est produite
