M
Membre supprimé 1060554
Invité
Il semble clair que la nappe SATA interne est HS. Car le SDD en USB externe --> tu as pu exécuter la commande de recréation d'une GPT + partition EFI > là où le SSD en interne l'opération échouait.
----------
La recréation spéculative d'un descripteur GPT de la partition apfs disparue en même temps que la GPT primitive --> a confirmé que le bloc n°409640 est bien le super-bloc du système de fichiers apfs toujours inscrit sur les blocs : le bloc d'initialisation de ce système de fichiers.
----------
Voici le mécanisme logique qui rend ingrat la maniement d'un système de fichiers apfs -->
----------
Cet éclaircissement donné > une action de vérification de l'apfs du Conteneur > si le super-bloc du Conteneur peut être lu --> affiche en regard la taille physique du Physical Store et la taille logique attendue du Conteneur stockée dans son super-bloc. De sorte que rééditer le descripteur GPT de la partition apfs en alignant l'extension de la partition et par là la taille du Physical Store => sur la taille logique du Conteneur inscrite dans le super-bloc --> a pour conséquence la suppression de l'erreur de taille +ERROR et le remontage des volumes.
Question : y avait-il en queue de disque une autre partition que celle de l'apfs - genre une partition BOOTCAMP ?
[Note : je reviendrai dans le fil vers les 10H disons.]
- on peut même conjecturer qu'une défaillance brusque de la nappe SATA ait occasionné la disparition de la table GPT directrice de l'en-tête du SSD. Jusqu'où cette défaillance de la nappe SATA a-t-elle porté des effets sur le disque => reste à voir.
----------
La recréation spéculative d'un descripteur GPT de la partition apfs disparue en même temps que la GPT primitive --> a confirmé que le bloc n°409640 est bien le super-bloc du système de fichiers apfs toujours inscrit sur les blocs : le bloc d'initialisation de ce système de fichiers.
- mais la génération d'un Conteneur affecté d'une erreur de taille +ERROR --> avère que l'extension (en nombre de blocs) attribuée spéculativement à la partition apfs => est erronée. Comme il s'agit de l'extension maximum possible => cette extension spéculative est donc excédentaire par rapport à la taille initiale de la partition apfs.
----------
Voici le mécanisme logique qui rend ingrat la maniement d'un système de fichiers apfs -->
- la partition apfs primaire du disque équivaut à un magasin de stockage physique appelé Physical Store. Ce Physical Store a une taille identique (en nombre de blocs) à la taille de la partition.
- le Physical Store sert de base de données --> à partir de laquelle se trouve virtualisé un espace-disque logique appelé Conteneur (Conteneur hébergeant une famille de volumes logiques). L'espace-disque virtuel du Conteneur doit avoir exactement la même taille en nombre de blocs (au bloc près) que le magasin de stockage physique. Cette taille du Conteneur se trouve enregistrée dans le super-bloc du Conteneur> càd. le composant décrivant synthétiquement cet espace-disque virtuel. Si la partition apfs primaire avec son Physical Store subit une variation de taille > sans que le super-bloc du Conteneur n'ait été mis-à-jour de cette variation > le super-bloc du Conteneur continue de requérir la taille en blocs antérieure --> qui ne correspond plus à l'identique avec la taille modifiée du Physical Store. Une erreur de taille +ERROR de la taille logique du Conteneur rapportée à la taille physique du Physical Store --> se trouve alors générée. L'ennui avec la sophistication de l'apfs => c'est que cette erreur de taille est invalidante quant à la possibilité de monter les volumes du Conteneur > là où une erreur de taille dans l'ancien système de fichiers jhfs+ n'avait pas d'effet invalidant du montage du volume correspondant à la partition.
----------
Cet éclaircissement donné > une action de vérification de l'apfs du Conteneur > si le super-bloc du Conteneur peut être lu --> affiche en regard la taille physique du Physical Store et la taille logique attendue du Conteneur stockée dans son super-bloc. De sorte que rééditer le descripteur GPT de la partition apfs en alignant l'extension de la partition et par là la taille du Physical Store => sur la taille logique du Conteneur inscrite dans le super-bloc --> a pour conséquence la suppression de l'erreur de taille +ERROR et le remontage des volumes.
- la vérification dans ton cas a attesté d'une corruption du super-bloc du Conteneur qui est donc illisible. Je ne sais donc pas quelle est la taille logique attendue par le Conteneur apfs > de manière à aligner dessus l'extension physique de la partition apfs. Cette corruption du super-bloc est-elle due au fait que l'extension de la partition est plus grande que la taille logique du Conteneur > ce qui fait qu'il conviendrait d'expérimenter une re-description diminuée de partition --> pour que la taille logique du super-bloc devienne plus grande que la taille physique de la partition ? - il va falloir tester ce cas de figure. Sinon > il faudra admettre que la défaillance de la nappe SATA n'a pas fait que faire sauter la GPT directrice > mais qu'elle a aussi corrompu le super-bloc du Conteneur apfs.
Question : y avait-il en queue de disque une autre partition que celle de l'apfs - genre une partition BOOTCAMP ?
[Note : je reviendrai dans le fil vers les 10H disons.]