Impossible de booter sur OSX

PonchoYa

Nouveau membre
7 Avril 2020
8
0
33
Voila déjà le résultat de plusieurs commande :

Bloc de code:
-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

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
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 :
Bloc de code:
diskutil info disk0s2
  • qui affiche un tableau d'informations sur la partition

Poste le retour.
 

PonchoYa

Nouveau membre
7 Avril 2020
8
0
33
Merci pour ta réponse !

Voila le retour :
Bloc de code:
-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

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
Aucun système de fichiers signalé. Passe la commande :
Bloc de code:
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

Nouveau membre
7 Avril 2020
8
0
33
voila :

Bloc de code:
-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

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
Pas très engageant tout ça.

- passe encore la commande :​
Bloc de code:
diskutil ap list
  • qui affiche des informations sur le système de fichiers apfs - si trouvé

Poste le retour.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
Passe la commande :
Bloc de code:
diskutil repairDisk disk0
  • à validation > une demande de confirmation s'affiche => tape y (yes) 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

Nouveau membre
7 Avril 2020
8
0
33
Voila :

Bloc de code:
-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

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
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

Nouveau membre
7 Avril 2020
8
0
33
Non je n'ai pas utilisé ce genre de programme.
oui, c'était bien Catalina, avec les dernières mise a jour.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
Le descripteur de la partition dans la table GPT -->
Bloc de code:
      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 partition2 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 :
Bloc de code:
diskutil list internal
  • qui affiche la configuration interne seule.
 
  • J’aime
Réactions: ogee

PonchoYa

Nouveau membre
7 Avril 2020
8
0
33
Merci pour les explications

Bloc de code:
-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

Nouveau membre
8 Avril 2020
7
0
34
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:
-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 :merci:
 
Dernière édition par un modérateur:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
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 rang1 - 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 -->
Bloc de code:
      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 :
Bloc de code:
   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

Nouveau membre
8 Avril 2020
7
0
34
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?
 
Dernière édition:

ogee

Nouveau membre
8 Avril 2020
7
0
34
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:

Bash:
[~] $ 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.
 

Fichiers joints

Dernière édition par un modérateur:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 260
Forêt de Fontainebleau
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 -->
Bloc de code:
/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 -->
Bloc de code:
    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 rang1 > 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.