# Impossible de booter sur OSX



## PonchoYa (7 Avril 2020)

Bonjour a tous, 

Depuis hier, et sans raison particulière, je n'arrive plus à booter ma partition Mac Os sur mon Macbook Pro 2016.
Seul ma partion windows s'affiche au démarrage.
Mon problème est globalement similaire à celui traité dans ce post : https://forums.macg.co/threads/impo...zgw94BGcWGR5jgo7X-RwlMMGf15yxj3MVCim2yAkS4tnE

quelqu'un peut m'aider svp ? 
@macomaniac ?


----------



## PonchoYa (7 Avril 2020)

Voila déjà le résultat de plusieurs commande : 


```
-bash-3.2# diskutil list disk0
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         1.0 TB     disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS                         799.1 GB   disk0s2
   3:       Microsoft Basic Data Windows                 200.7 GB   disk0s3
   4:           Windows Recovery                         497.0 MB   disk0s4
-bash-3.2# gpt -r show disk0
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2          4         Pri GPT table
          6      76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      76806  195082746      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  195159552   48995014      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  244154566         58         
  244154624     121344      4  GPT part - DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
  244275968        292         
  244276260          4         Sec GPT table
  244276264          1         Sec GPT header
-bash-3.2# diskutil cs list
No CoreStorage logical volume groups found
-bash-3.2# diskutil ap list
No APFS Containers found
-bash-3.2#
```

Pour info je suis sur Catalina 10.15 et Filevault était activé.


----------



## macomaniac (8 Avril 2020)

Bonjour *PonchoYa*

Je vois bien la partition de type "*Apple_APFS*" au rang n°*2* des partitions. Dans la mesure où Catalina était installé > le type de la partition est adéquat.

- le problème est qu'aucun *Conteneur apfs* ne se trouve virtualisé à partir de la partition.​
Passe la commande :

```
diskutil info disk0s2
```


qui affiche un tableau d'informations sur la partition

Poste le retour.


----------



## PonchoYa (8 Avril 2020)

Merci pour ta réponse ! 

Voila le retour : 

```
-bash-3.2# diskutil info disk0s2
   Device Identifier:        disk0s2
   Device Node:              /dev/disk0s2
   Whole:                    No
   Part of Whole:            disk0

   Volume Name:              Not applicable (no file system)
   Mounted:                  Not applicable (no file system)
   File System:              None

   Partition Type:           Apple_APFS
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 PCI-Express
   SMART Status:             Not Supported
   Disk / Partition UUID:    42B60681-B193-40F8-AAD5-B2B2F43BD538

   Disk Size:                799.1 GB (799058927616 Bytes) (exactly 1560661968 512-Byte-Units)
   Device Block Size:        4096 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)

   Device Location:          Internal
   Removable Media:          Fixed

   Solid State:              Yes
```


----------



## macomaniac (8 Avril 2020)

Aucun système de fichiers signalé. Passe la commande :

```
diskutil verifyVolume disk0s2
```


qui vérifie le système de fichiers inscrit sur l'en-tête de la partition (s'il y en a un)

Poste le retour.


----------



## PonchoYa (8 Avril 2020)

voila : 


```
-bash-3.2# diskutil verifyVolume disk0s2
Started file system verification on disk0s2
Verifying storage system
Storage system check exit code is 8
Error: -69716: Storage system verify or repair failed
Underlying error: 8: Exec format error
```


----------



## macomaniac (8 Avril 2020)

Pas très engageant tout ça.

- passe encore la commande :​

```
diskutil ap list
```


qui affiche des informations sur le système de fichiers *apfs* - si trouvé

Poste le retour.


----------



## PonchoYa (8 Avril 2020)

```
-bash-3.2# diskutil ap list
No APFS Containers found
```


----------



## macomaniac (8 Avril 2020)

Passe la commande :

```
diskutil repairDisk disk0
```


à validation > une demande de confirmation s'affiche => tape *y* (*y*es) et revalide

la commande lance une réparation totale du disque > dont celle de la table *GPT* qui gère les partitions

Poste le retour.


----------



## PonchoYa (8 Avril 2020)

Voila :


```
-bash-3.2# diskutil repairDisk disk0
Repairing the partition map might erase disk0s1, proceed? (y/N) y
Started partition map repair on disk0
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Updating Windows boot.ini files as required
The partition map appears to be OK
Finished partition map repair on disk0
```


----------



## macomaniac (8 Avril 2020)

Pas de problème de table de partition.

- j'ai l'impression que le partition de type "*Apple_APFS*" est une coquille vide de système de fichiers *apfs* (formateur de volumes virtuels dans un *Conteneur*). Comme si l'*apfs* avait été effacé.​
Questions : tu n'as pas utilisé de programme manipulateur de partitions dans Windows ? - c'était bien Catalina (un OS *apfs*) qui était installé ?


----------



## PonchoYa (8 Avril 2020)

Non je n'ai pas utilisé ce genre de programme.
oui, c'était bien Catalina, avec les dernières mise a jour.


----------



## macomaniac (8 Avril 2020)

Le descripteur de la partition dans la table *GPT* -->

```
76806  195082746      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
```


ne présente pas d'anomalie. Il assigne en bloc de tête le *1er* bloc libre après la partition auxiliaire *EFI*. Une extension correspondant aux blocs disponibles entre la partition *EFI* et la *Windows*. Un rang de partition n°*2* valide. Un type de partition : "*Apple_APFS*" (via l'*UUID* de ce type = *7C3457EF-0000-11AA-AA11-00306543ECAC*) adéquat. Je ne vois rien à redire à ce niveau. Le descripteur ne me paraît pas avoir été modifié.

c'est le système de fichiers *apfs* inscrit sur les blocs de tête de la partition qui me paraît avoir disparu. Son super-bloc ou bloc d'initialisation devait être le n°*76806* = *1er* bloc de la partition décrite. Tout se passe comme s'il y avait eu effacement sans reformatage (qui aurait recréé un nouveau système de fichiers formateur de volumes).

Redémarre une fois en revenant via *⌘⌥R* (*command option R*) dans une session Catalina > puis poste le tableau d'une commande :

```
diskutil list internal
```


qui affiche la configuration interne seule.


----------



## PonchoYa (8 Avril 2020)

Merci pour les explications 


```
-bash-3.2# diskutil list internal
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS                         799.1 GB   disk0s2
   3:       Microsoft Basic Data Windows                 200.7 GB   disk0s3
   4:           Windows Recovery                         497.0 MB   disk0s4
```


----------



## ogee (8 Avril 2020)

Merci beaucoup pour ton aide @macomaniac .

Je me permets d'intervenir car en lisant la réponse à une cette question stackexchange, il me semble qu'une des sources du problème serait le fait que la taille de sa partition (195082746) n'est pas divisible par 8. Je n'ai pas osé proposer à @PonchoYa une commande de type "gpt add/remove" comme proposée sur la réponse car j'ai peur de me tromper dans les paramètres et du coup de lui rendre sa partition Recovery ou Bootcamp inaccessible.

J'ai remarqué ça en comparant avec le résultat des mêmes commandes sur un macbook pro Catalina (mais sans Bootcamp) qui marche bien, où la taille de la partition mac (3932000) est divisible par 8:

```
-bash-3.2# diskutil list disk0
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.7 GB   disk0s2
-bash-3.2# gpt -r show disk0
    start     size  index  contents
        0        1         PMBR
        1        1         Pri GPT header
        2       32         Pri GPT table
       34        6     
       40  3932000      1  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  3932040   262151     
  4194191       32         Sec GPT table
  4194223        1         Sec GPT header
```


Je m'excuse par avance si mon intervention n'est pas pertinente ou carrément hors sujet, car le grand serpent cosmique a l'air de t'avoir doté de beaucoup plus de connaissances que moi sur ce sujet


----------



## macomaniac (8 Avril 2020)

Bonsoir *ogee*

La table de la distribution des blocs de ton propre disque que tu affiches montre que -->

- la taille du bloc de référence chez toi est le standard de *512* octets. L'extension de la partition n'a pas par suite à être divisible par *8* > puisque le bloc ici assigné est l'unité de bloc élémentaire (la plus petite unité de bloc utilisée - le bloc étant l'unité élémentaire du point de vue de l'écriture d'un fichier) = *512* octets. Il suffit dans ce cas que l'extension soit un nombre pair et pas impair - ce qu'elle chez toi.​​- le type de la partition chez toi est "*Apple_HFS*" (désigné par l'*UUID* de type = *48465300-0000-11AA-AA11-00306543ECAC*). Elle héberge donc un système de fichiers *jhfs+* > formant un volume *Macintosh HD* (si pas renommé) standard et non chiffré par FileVault.​​- il manque chez toi une partition *EFI* de *209,7 Mo* au rang n°*1* - partition dédiée au programme interne du Mac (= *EFI*) pour ses mises à jour de *firmware* ou autres. Elle devrait avoir pour bloc de tête le n°*40* (pris comme bloc de tête par la partition de l'OS) > et une extension de *409600* blocs de *512* octets (bloc de tête inclus dans le compte) = *209,7 Mo*.​
----------

Comme tu attires mon attention sur la partition *apfs* décrite sur le disque de *PonchoYa* -->

```
76806  195082746      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
```


l'extension est de *195082746* blocs. Paire comme voulue. Mais il s'agit ici d'une taille de bloc de référence *octuple* du standard de *512* octets = *4096* octets. Ces *195082746* blocs de *4096* octets par unité de bloc => équivalent donc à *195082746* blocs x *8* blocs standards de *512* octets = *1560661968* blocs de *512* octets = *799.05 Go* => soit la taille de la partition décrite sur le disque :


```
2:                 Apple_APFS                         799.1 GB   disk0s2
```


j'ai vu que la taille du bloc de référence était l'*octuple* du standard de *512* octets = *4096* octets => au fait que la *GPT* principale de début du disque occupe *5* blocs seulement au lieu des *33* blocs habituels avec le standard de bloc de *512* octets. Donc il s'agit de *5* blocs de *4096* octets = *40* blocs standards.

la taille du bloc de référence chez *PonchYa* étant de *4096* octets => l'extension de la partition est nécessairement un *multiple* de *8* de la taille équivalente en blocs de *512* octets. Elle n'a pas à être divisible par *8* mais à être multipliée par *8* pour donner l'équivalent en blocs de *512* octets standards - chaque bloc étant a priori un octuple du bloc standard.

=> tout me dit que le descripteur *GPT* de la partition de type *apfs* chez *PonchoYa* n'a pas été corrompu. Mais que le système de fichiers *apfs* qui était inscrit sur les blocs de début de la partition > à partir du bloc n° *76806* qui devait être le super-bloc ou bloc d'initialisation du système de fichiers => a été effacé des blocs.

Note : ton lien est corrompu (je n'arrive pas à ouvrir la page).


----------



## ogee (8 Avril 2020)

Ha désolé pour le lien :/ Je n'arrive pas à le modifier en plus. Voici le  lien en question:
https:// apple.stackexchange.com/questions/340097/apfs-partition-inaccessible-container-missing

Merci beaucoup pour tes explications, je comprends mieux cette histoire d'octuple maintenant! Du coup tu penses que les premiers blocs ont été effacées et qu'on ne peut rien faire pour PonchoYa? On peut peut-être verifier cela avec "dd | hexdump" comme l'indique le lien stackexchange?


----------



## macomaniac (8 Avril 2020)

Je n'arrive toujours pas à ouvrir la page. J'obtiens le message : "The link you clicked on is malformed. Contact the editor of the originating page".


----------



## ogee (8 Avril 2020)

Oui moi aussi.. Pourtant c'est bien le bon lien. On dirait que ça ne vient pas de moi...
https:// apple.stackexchange.com/questions/340097/apfs-partition-inaccessible-container-missing

EDIT: Je confirme ça ne vient pas de moi. J'ai pensé a une extension Chrome malicieuse mais ça me fait la même chose sur différents navigateurs... Le forum a un soucis, je ne vois que ça.

Par contre je reviens sur ton analyse du dique dur de mon macbook qui d'ailleurs ne me pose aucun soucis durant les MAJ EFI:  je ne pense vraiment pas que la partition désignée par l'UUID  = 48465300-0000-11AA-AA11-00306543ECAC est en HFS+ et non chiffrée par FileVault comme tu l'indiques.
Tu peux constater cela dans le résultat de ces commandes que j'ai lancées sur ma session et la capture d'écran en PJ:


```
[~] $ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.7 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Data     203.7 GB   disk1s1
   2:                APFS Volume Preboot                 80.7 MB    disk1s2
   3:                APFS Volume Recovery                528.1 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
   5:                APFS Volume Macintosh HD            11.2 GB    disk1s5

[~] $ sudo fdesetup status
Password:
FileVault is On.
```


----------



## macomaniac (8 Avril 2020)

L'*UUID* : *48465300-0000-11AA-AA11-00306543ECAC* est par convention le désignateur universel du type de partition : "*Apple_HFS*".

- c'est l'*UUID* : *7C3457EF-0000-11AA-AA11-00306543ECAC* qui est le désignateur universel du type de partition : "*Apple_APFS*".​
Il est impossible a priori qu'une partition de type "*Apple_APFS*" soit décrite par un descripteur *GPT* qui lui assignerait comme *UUID* : *48465300-0000-11AA-AA11-00306543ECAC* de type : "*Apple_HFS*".

La configuration du disque que tu affiches -->

```
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.7 GB   disk0s2
```


n'a *rien à voir* avec la distribution sous-jacente de blocs que tu avais affiché antérieurement -->


```
start     size  index  contents
        0        1         PMBR
        1        1         Pri GPT header
        2       32         Pri GPT table
       34        6      
       40  3932000      1  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  3932040   262151      
  4194191       32         Sec GPT table
  4194223        1         Sec GPT header
```


car la configuration pour le *kernel* montre *2* partitions dont une partition *EFI* au rang n°*1* > alors que la distribution de blocs *GPT* ne montre qu'*1* partition et pas de partition *EFI*.

l'extension de la partition est de *3932000* blocs de *512* octets = *2.01 Go* soit la taille du volume de l'image-disque recelant un OS de secours démarré.

l'invite de commande *-bash-3.2#* qui précédait le tableau des blocs montre que la commande a été passée dans le *terminal* de la session de secours ouverte.

Conclusion : le *disk0* indexait alors l'image-disque de l'OS de secours démarré > et pas le disque interne du Mac d'une capacité de *251 Go* qui devait avoir été indexé *disk1*. Bref : ta commande s'est trompée de cible.


----------



## ogee (8 Avril 2020)

macomaniac a dit:


> L'*UUID* : *48465300-0000-11AA-AA11-00306543ECAC* est par convention le désignateur universel du type de partition : "*Apple_HFS*".
> 
> - c'est l'*UUID* : *7C3457EF-0000-11AA-AA11-00306543ECAC* qui est le désignateur universel du type de partition : "*Apple_APFS*".​
> Il est impossible a priori qu'une partition de type "*Apple_APFS*" soit décrite par un descripteur *GPT* qui lui assignerait comme *UUID* : *48465300-0000-11AA-AA11-00306543ECAC* de type : "*Apple_HFS*".
> ...



Bien vu! Je suis désolé effectivement vu que j'arrivais pas a faire de "gpt show" sur ma session j'ai booté sur le Recovery, d'où l'incohérence entre les deux commandes. Par contre pour PonchoYa tu penses qu'on peut faire quelque chose?


----------



## macomaniac (8 Avril 2020)

Le *SIP* (protocole de sécurisation) activé interdit la lecture de la table *GPT* à la commade *gpt* depuis la session d'utilisateur. Il faut donc désactiver le *SIP* pour utiliser la commande *gpt* dans le *terminal* de l'OS démarré.

- démarre en mode secours > passe la commande :​

```
csrutil disable
```


qui désactive le *SIP* (commande invalide dans le *terminal* de la session d'utilisateur)

- de retour dans ta session > tu peux alors passer la commande :​

```
sudo gpt show disk0
```


qui affiche la distribution des blocs du disque interne

Note : *sudo* obligé avec *gpt* dans le *terminal* de la session d'utilisateur. Ce qui retourne une demande de *password* : tu tapes en aveugle ton mot-de-passe de session (admin) et tu revalides.


----------



## ogee (9 Avril 2020)

Ha OK le SIP bloquait le "gpt show". Merci de l'info je retentirai demain le "gpt show" demain. Mais j'ai l'impression que mon intervention foireuse avec le lien qui marche pas, mes commandes foireuses et mon fixage sur les octuples, on en a un peu oublié PonchoYa, du coup je m'en veux un peu lol. D'autant plus que mon mac n'a pas de soucis en plus 

En tout cas un grand merci pour ton aide et ta pédagogie, j'ai appris plein de trucs grâce à toi. Je te laisse avec PonchoYa!


----------



## macomaniac (9 Avril 2020)

Il arrive dans un même fil que plusieurs conversations s'entremêlent. Dans les grands romans d'Ancien Français du XIIIè siècle (comme le Lancelot en Prose ou le Tristan en Prose) > ce procédé est appelé l'« entrelacement ». Tant que l'entrelacement intervient comme ici en tenant compte de suspensions logiques d'une conversation pour donner carrière à une nouvelle : ça ne crée pas de confusion.


----------



## ogee (14 Avril 2020)

Hello,

PonchoYa a réussi a retrouver sa session grâce à l'aide de klanomath, un utilisateur de StackExchange. Du coup je vais poster sa solution sur ce forum au cas où ça pourrait aider quelqu'un. Par contre, je n'arrive pas mettre le lien de la réponse StackExchange sans que le lien devienne corrompu donc je le mets avec un espace aprés le https:
https:// apple.stackexchange.com/questions/387732/unable-to-boot-on-my-apfs-partition

Pour info, la cause du probleme serait que le superblock du container APFS a été réécrit par un MBR, probablement suite à un arrêt inopiné du macbook, dû à une batterie defectueuse aprés seulement 400cycles, .

On peut le voir ici:

```
-bash-3.2# dd if=/dev/disk0 bs=512 count=1 skip=614448 2>/dev/null | vis -wc; echo
3\M-@\M^N\M-P\M-<\0|\M^N\M-@\M^N\M-X\M->\0|\M-?\0\^F\M-9\0\^B\M-|\M-s\M-$Ph\^\\^F\M-K\M-{\M-9\^D\0\M-=\M->\a\M^@~\0\0|\v\^O\M^E\^P\^A\M^C\M-E\^P\M-b\M-q\M-M\^X\M^HV\0U\M-FF\^Q\^E\M-FF\^P\0\M-4A\M-;\M-*U\M-M\^S]r\^O\M^A\M-{U\M-*u\t\M-w\M-A\^A\0t\^C\M-~F\^Pf`\M^@~\^P\0t&fh\0\0\0\0f\M^?v\bh\0\0h\0|h\^A\0h\^P\0\M-4B\M^JV\0\M^K\M-t\M-M\^S\M^_\M^C\M-D\^P\M^^\M-k\^T\M-8\^A\^B\M-;\0|\M^JV\0\M^Jv\^A\M^JN\^B\M^Jn\^C\M-M\^Sfas\^^\M-~N\^Q\^O\M^E\f\0\M^@~\0\M^@\^O\M^D\M^J\0\M-2\M^@\M-k\M^BU2\M-d\M^JV\0\M-M\^S]\M-k\M^\\M^A>\M-~}U\M-*un\M^?v\0\M-h\M^J\0\^O\M^E\^U\0\M-0\M-Q\M-fd\M-h\^?\0\M-0\M-_\M-f`\M-hx\0\M-0\M^?\M-fd\M-hq\0\M-8\0\M-;\M-M\^Zf#\M-@u;f\M^A\M-{TCPAu2\M^A\M-y\^B\^Ar,fh\a\M-;\0\0fh\0\^B\0\0fh\b\0\0\0fSfSfUfh\0\0\0\0fh\0|\0\0fah\0\0\a\M-M\^ZZ2\M-v\M-j\0|\0\0\M-M\^X\240\M-7\a\M-k\b\240\M-6\a\M-k\^C\240\M-5\a2\M-d\^E\0\a\M^K\M-p\M-,<\0t\M-|\M-;\a\0\M-4\^N\M-M\^P\M-k\M-r+\M-I\M-dd\M-k\0$\^B\M-`\M-x$\^B\M-CInvalid\spartition\stable\0Error\sloading\soperating\ssystem\0Missing\soperating\ssystem\0\0\0\0bz\M^Yq\^T\^Q\^Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0U\M-*
```


```
[~] $ echo -n '3\M-@\M^N\M-P\M-<\0|\M^N\M-@\M^N\M-X\M->\0|\M-?\0\^F\M-9\0\^B\M-|\M-s\M-$Ph\^\\^F\M-K\M-{\M-9\^D\0\M-=\M->\a\M^@~\0\0|\v\^O\M^E\^P\^A\M^C\M-E\^P\M-b\M-q\M-M\^X\M^HV\0U\M-FF\^Q\^E\M-FF\^P\0\M-4A\M-;\M-*U\M-M\^S]r\^O\M^A\M-{U\M-*u\t\M-w\M-A\^A\0t\^C\M-~F\^Pf`\M^@~\^P\0t&fh\0\0\0\0f\M^?v\bh\0\0h\0|h\^A\0h\^P\0\M-4B\M^JV\0\M^K\M-t\M-M\^S\M^_\M^C\M-D\^P\M^^\M-k\^T\M-8\^A\^B\M-;\0|\M^JV\0\M^Jv\^A\M^JN\^B\M^Jn\^C\M-M\^Sfas\^^\M-~N\^Q\^O\M^E\f\0\M^@~\0\M^@\^O\M^D\M^J\0\M-2\M^@\M-k\M^BU2\M-d\M^JV\0\M-M\^S]\M-k\M^\\M^A>\M-~}U\M-*un\M^?v\0\M-h\M^J\0\^O\M^E\^U\0\M-0\M-Q\M-fd\M-h\^?\0\M-0\M-_\M-f`\M-hx\0\M-0\M^?\M-fd\M-hq\0\M-8\0\M-;\M-M\^Zf#\M-@u;f\M^A\M-{TCPAu2\M^A\M-y\^B\^Ar,fh\a\M-;\0\0fh\0\^B\0\0fh\b\0\0\0fSfSfUfh\0\0\0\0fh\0|\0\0fah\0\0\a\M-M\^ZZ2\M-v\M-j\0|\0\0\M-M\^X\240\M-7\a\M-k\b\240\M-6\a\M-k\^C\240\M-5\a2\M-d\^E\0\a\M^K\M-p\M-,<\0t\M-|\M-;\a\0\M-4\^N\M-M\^P\M-k\M-r+\M-I\M-dd\M-k\0$\^B\M-`\M-x$\^B\M-CInvalid\spartition\stable\0Error\sloading\soperating\ssystem\0Missing\soperating\ssystem\0\0\0\0bz\M^Yq\^T\^Q\^Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0U\M-*' | unvis | hexdump -Cv
00000000  33 c0 8e d0 bc 00 7c 8e  c0 8e d8 be 00 7c bf 00  |3.....|......|..|
00000010  06 b9 00 02 fc f3 a4 50  68 1c 06 cb fb b9 04 00  |.......Ph.......|
00000020  bd be 07 80 7e 00 00 7c  0b 0f 85 10 01 83 c5 10  |....~..|........|
00000030  e2 f1 cd 18 88 56 00 55  c6 46 11 05 c6 46 10 00  |.....V.U.F...F..|
00000040  b4 41 bb aa 55 cd 13 5d  72 0f 81 fb 55 aa 75 09  |.A..U..]r...U.u.|
00000050  f7 c1 01 00 74 03 fe 46  10 66 60 80 7e 10 00 74  |....t..F.f`.~..t|
00000060  26 66 68 00 00 00 00 66  ff 76 08 68 00 00 68 00  |&fh....f.v.h..h.|
00000070  7c 68 01 00 68 10 00 b4  42 8a 56 00 8b f4 cd 13  ||h..h...B.V.....|
00000080  9f 83 c4 10 9e eb 14 b8  01 02 bb 00 7c 8a 56 00  |............|.V.|
00000090  8a 76 01 8a 4e 02 8a 6e  03 cd 13 66 61 73 1e fe  |.v..N..n...fas..|
000000a0  4e 11 0f 85 0c 00 80 7e  00 80 0f 84 8a 00 b2 80  |N......~........|
000000b0  eb 82 55 32 e4 8a 56 00  cd 13 5d eb 9c 81 3e fe  |..U2..V...]...>.|
000000c0  7d 55 aa 75 6e ff 76 00  e8 8a 00 0f 85 15 00 b0  |}U.un.v.........|
000000d0  d1 e6 64 e8 7f 00 b0 df  e6 60 e8 78 00 b0 ff e6  |..d......`.x....|
000000e0  64 e8 71 00 b8 00 bb cd  1a 66 23 c0 75 3b 66 81  |d.q......f#.u;f.|
000000f0  fb 54 43 50 41 75 32 81  f9 02 01 72 2c 66 68 07  |.TCPAu2....r,fh.|
00000100  bb 00 00 66 68 00 02 00  00 66 68 08 00 00 00 66  |...fh....fh....f|
00000110  53 66 53 66 55 66 68 00  00 00 00 66 68 00 7c 00  |SfSfUfh....fh.|.|
00000120  00 66 61 68 00 00 07 cd  1a 5a 32 f6 ea 00 7c 00  |.fah.....Z2...|.|
00000130  00 cd 18 a0 b7 07 eb 08  a0 b6 07 eb 03 a0 b5 07  |................|
00000140  32 e4 05 00 07 8b f0 ac  3c 00 74 fc bb 07 00 b4  |2.......<.t.....|
00000150  0e cd 10 eb f2 2b c9 e4  64 eb 00 24 02 e0 f8 24  |.....+..d..$...$|
00000160  02 c3 49 6e 76 61 6c 69  64 20 70 61 72 74 69 74  |..Invalid partit|
00000170  69 6f 6e 20 74 61 62 6c  65 00 45 72 72 6f 72 20  |ion table.Error |
00000180  6c 6f 61 64 69 6e 67 20  6f 70 65 72 61 74 69 6e  |loading operatin|
00000190  67 20 73 79 73 74 65 6d  00 4d 69 73 73 69 6e 67  |g system.Missing|
000001a0  20 6f 70 65 72 61 74 69  6e 67 20 73 79 73 74 65  | operating syste|
000001b0  6d 00 00 00 00 62 7a 99  71 14 11 19 00 00 00 00  |m....bz.q.......|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200
```


On peut le comparer avec un superblock normal de conteneur APFS :





Du coup voici les étapes pour la résolution du probléme en anglais:


> To fix this (via TeamViewer & external boot volume with Catalina installed) another (older) superblock of disk0s2 was used to overwrite the MBR data.
> 
> 
> Install HexFiend and search for the magic bytes of a superblock: NXSB on partition disk0s2. The first occurance was after the first ~3 GB of disk0s2. The metadata part of an APFS container usually houses various older superblocks. The current superblock usually is the copy of *one* "older" superblock if the Mac was shut down properly previously.
> ...



Voilà, et encore merci  @macomaniac pour ton aide!


----------



## macomaniac (15 Avril 2020)

Bonjour *ogee*

J'ai réussi à trouver le fil où se trouve exposée l'intervention de *klanomath*. Je te livre mes impressions -->

- belle technique de la commande *dd* (*d*ata_*d*oubler) - dont personnellement je ne me sers que rarement (mais j'ai peut-être tort).​​- théorisation contestable : il assume que le super-bloc de l'*apfs* a été réécrit par le bloc n°*0* qui porte la table de partition  *MBR* du disque. Or il raisonnne constamment _comme si_ le bloc n°*0* en question avait une taille de *512* octets (bloc standard) => ce qui fait que les seuls *512* octets initiaux du super-bloc de l'*apfs* auraient été écrasés > un super-bloc *apfs* ayant une taille réglementaire de *1382* octets. Il resterait donc *1382* octets - *512* octets = *870* octets de super-bloc non  écrasés. Or sachant que se trouve stockés plusieurs *backups* logiques de super-bloc > les *512* octets suivant les *512* octets écrasés par les *512* octets de la *MBR* => auraient des chances de receler un *backup* de superbloc opérationnel pour initialiser le *Conteneur apfs*. Il a donc copié (via *dd*) les octets allant du *513è* au *1024è* > puis il es a restaurés sur les octets *1* à *512* du super-bloc *apfs* qui avaient été écrasés. Il faut croire que ça aurait marché.​​- il y a une objection fondamentale à cette recréation spéculative. C'est que le gabarit de bloc actif sur le disque de *PonchoYa* est le bloc octuple de *4096* octets. Ce qui se voit au fait que la table *GPT* directrice occupe les seuls blocs *1* => *5* > alors qu'elle occupe les blocs *1* > *33* lorsque le gabarit de blocs est le standard de *512* octets. Donc le gabarit de bloc est bien le bloc octuple de *4096* octets. Voici alors la conséquence qui s'en tire : le bloc n°*0* où se trouve inscrite la table *MBR* alternative => ne fait absolument pas *512* octets comme il le présume > mais *4096* octets. S'il y a eu écrasement du super-bloc de l'*apfs* > ce n'est donc pas par les *512* octets d'un bloc n°*0* *MBR* standard > mais par les *4096* octets du bloc n°*0* *MBR* actif. Son argument que les *870* octets suivant les *512* octets initiaux du super-bloc *apfs* seraient valides car non écrasés => est donc invalide > puisqu'il y a eu écrasement par les *4096* octets du bloc n°*0* réel de la *MBR*.​
En résumé : il plaque constamment un schéma expérimental correspondant à une computation en unité de blocs de *512* octets => sur un disque régi par une computation d'unités de blocs de *4096* octets. Je ne vois franchement pas comment ça pourrait marcher. Il a apparemment pris la maîtrise via TeamViewer du Mac à problème : j'en déduis que la restituation écrite qu'il donne après-coup de ses interventions et qui correspond à un disque régi par une computation de bloc de *512* octets => ne peut pas restituer les opérations qu'il aurait effectuées en mode *live*.


----------

