10.13 High Sierra Gros probleme sur MBP

Heisenberg92100

Membre confirmé
11 Octobre 2017
31
0
40
Boulogne-Billancourt
bonjour a tous

Je suis desespere :-(
J’ai installé High Sierra sur mon MBP de fin 2013. Cependant comme beaucoup, j’ai l’ecran « Disk Password » qui s´affiche.

J’ai donc decidé de booter mon MBP sur une clé pour l’installation de High Sierra et j’ai egalement fais l’instal sur un DD EXTERNE afin de pouvoir recuperer mes données ultra precieuse. J’avais donc la possibilite de saisir mon mot de passe pour deverouiller le « macintosh hd » et j’ai debuté ma sauvegarde sur le DD EXTERNE. Sauf que le matin je retrouve mon MBP figé et lorsque je redemarre, impossible de monter mon « Macintosh Hd » ni d’acceder a mes donnees sur le DD EXTERNE.
J’ai reformate le DD EXTERNE, refais une instal propre mais je m´appercois que je n’ai plus la possibiliter de deverouiller mon « Macintosh hd » que ce soit via l’utilitaire de disque ou meme en mode recovery.

Je ne veux pas formater mon macintosh jd en sachant qu’il faut absolument que je recupere mes donnees chiffrees (merci filevault :-()

J’ai vraiment besoin d’aide svp je craque
 
Salut

Dure dure la pente avec High Sierra.:D
Peux-tu donner les retours, depuis le terminal, des commandes :
diskutil list
et
diskutil ap list
Il faudra démarrer en mode Recovery (cmd+r lors du boot) puis Menu/Utilitaires/Terminal
En mode Recovery pour poster les résultats, il faudra faire un copier depuis le terminal, puis quitter et lancer safari (menu à 4 choix : Obtenir de l'aide) puis aller sur le forum et coller les résultats entre balises Code :
code-jpeg.113137
 
  • J’aime
Réactions: Heisenberg92100
Salut Jean, merci de me filer un coup de main c'est cool ;-)

Bloc de code:
-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk2         499.4 GB   disk0s2

/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +2.1 GB     disk1
   1:                  Apple_HFS OS X Base System        2.0 GB     disk1s1

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +499.4 GB   disk2
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            435.7 GB   disk2s1
   2:                APFS Volume Preboot                 9.7 MB     disk2s2
   3:                APFS Volume Recovery                520.0 MB   disk2s3

/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +5.2 MB     disk3

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *8.0 GB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:                  Apple_HFS Install macOS High S... 7.7 GB     disk4s2

/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:                 Apple_APFS Container disk6         499.2 GB   disk5s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk5s3

/dev/disk6 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +499.2 GB   disk6
                                 Physical Store disk5s2
   1:                APFS Volume Freecom                 20.5 KB    disk6s1

/dev/disk7 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk7

/dev/disk8 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk8

/dev/disk9 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk9

/dev/disk10 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk10

/dev/disk11 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk11

/dev/disk12 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk12

/dev/disk13 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +12.6 MB    disk13

/dev/disk14 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk14

/dev/disk15 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk15

/dev/disk16 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk16

/dev/disk17 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk17

/dev/disk18 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk18

/dev/disk19 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk19

/dev/disk20 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk20

/dev/disk21 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk21

/dev/disk22 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk22

/dev/disk23 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk23

-bash-3.2#

Bloc de code:
-bash-3.2# diskutil ap list
APFS Containers (2 found)
|
+-- Container disk2 219DBE3A-F2B2-4FAC-85B7-F98DEA51CB9B
|   ====================================================
|   APFS Container Reference:     disk2
|   Capacity Ceiling (Size):      499417919488 B (499.4 GB)
|   Capacity In Use By Volumes:   436401868800 B (436.4 GB) (87.4% used)
|   Capacity Available:           63016050688 B (63.0 GB) (12.6% free)
|   |
|   +-< Physical Store disk0s2 37254EF7-B98F-47C5-8ACB-0CA4CE163D2A
|   |   -----------------------------------------------------------
|   |   APFS Physical Store Disk:   disk0s2
|   |   Size:                       499417919488 B (499.4 GB)
|   |
|   +-> Volume disk2s1 23B577FB-859A-3948-A6E6-ED4953D71F26
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk2s1 (No specific role)
|   |   Name:                      Macintosh HD (Case-insensitive)
|   |   Mount Point:               Not Mounted
|   |   Capacity Consumed:         435710746624 B (435.7 GB)
|   |   Encrypted:                 Yes (Locked)
|   |
|   +-> Volume disk2s2 C90375AA-7765-4F81-ABB0-4CD4C378B4DD
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk2s2 (Preboot)
|   |   Name:                      Preboot (Case-insensitive)
|   |   Mount Point:               Not Mounted
|   |   Capacity Consumed:         9740288 B (9.7 MB)
|   |   Encrypted:                 No
|   |
|   +-> Volume disk2s3 0D398064-23B6-4984-8F8F-F4CDBEA6DB5A
|       ---------------------------------------------------
|       APFS Volume Disk (Role):   disk2s3 (Recovery)
|       Name:                      Recovery (Case-insensitive)
|       Mount Point:               Not Mounted
|       Capacity Consumed:         519995392 B (520.0 MB)
|       Encrypted:                 No
|
+-- Container disk6 F7F6D3D6-C6A8-4EF4-ADDD-31780F870FB0
    ====================================================
    APFS Container Reference:     disk6
    Capacity Ceiling (Size):      499248103424 B (499.2 GB)
    Capacity In Use By Volumes:   160788480 B (160.8 MB) (0.0% used)
    Capacity Available:           499087314944 B (499.1 GB) (100.0% free)
    |
    +-< Physical Store disk5s2 D73ACBAB-80C8-4A89-93AB-4F6364D9416A
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk5s2
    |   Size:                       499248103424 B (499.2 GB)
    |
    +-> Volume disk6s1 59800265-C651-4F65-B24C-CE239823A3A5
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk6s1 (No specific role)
        Name:                      Freecom (Case-insensitive)
        Mount Point:               /Volumes/Freecom
        Capacity Consumed:         20480 B (20.5 KB)
        Encrypted:                 No
-bash-3.2#
 
Dernière édition par un modérateur:
Bloc de code:
-bash-3.2# diskutil repairvolume disk2
Started file system repair on disk2
Repairing storage system
Performing fsck_apfs -y -x /dev/disk0s2
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
error: invalid dstream.default_crypto_id (0x4), given apfs_fs_flags (0x1)
error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
error: inode_val: object (oid 0xd3302c): invalid xfields
fsroot tree is invalid
The volume /dev/disk0s2 could not be verified completely
Storage system check exit code is 0
Finished file system repair on disk2
-bash-3.2#
 
Bloc de code:
-bash-3.2# diskutil repairvolume disk2s1
Started file system repair on disk2s1 Macintosh HD
Repairing file system
Volume is already unmounted
Performing fsck_apfs -y -x /dev/rdisk2s1
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
error: invalid dstream.default_crypto_id (0x4), given apfs_fs_flags (0x1)
error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
error: inode_val: object (oid 0xd3302c): invalid xfields
fsroot tree is invalid
The volume /dev/rdisk2s1 could not be verified completely
File system check exit code is 0
Restoring the original state found as unmounted
Finished file system repair on disk2s1 Macintosh HD
-bash-3.2#
 
Salut Heisenberg

Je m'immisce dans ton fil dans un rôle de commentateur.

L'opération de vérification / réparation que tu as lancée porte sur la structure du système de fichiers APFS dont dépend aussi bien le Container disk2 global que le volume Macintosh HD disk2s1.

Ce nouveau système de fichiers APFS est extraordinairement non documenté jusqu'à présent. Tu obtiens une erreur sur le composant suivant de sa structure :
Bloc de code:
fsroot tree is invalid

« l'arbre-racine du système de fichiers est invalide » (si je puis risquer cette traduction). Cette désignation me fait penser au traditionnel : « B-tree catalog » dans le système de fichiers JHFS+ --> à savoir, le fichier gérant l'adressage aux fichiers (considérés métaphoriquement comme des feuilles terminales) via une arborescence partant du point-de-montage considéré comme la racine (root) > et allant aux données terminales par une série de dérivations en embranchements (nodes) portant des clés (keys) numériques.

Dans l'ancien système de fichiers JHFS+ > des erreurs de nœuds (nodes) invalidaient toute l'arborescence qui en dérivait > et par là rendait impossible l'accès aux données terminales qui en relevaient pour lecture > édition > ajout > remplacement > suppression. Ces erreurs dans le catalogue B-tree était invalidantes (radicales) - le catalogue étant le noyau du système de fichiers.

Je ne sais pas si l'analogie verbale « B-tree catalog » --> « fsroot tree » permet de voir dans le fsroot tree l'héritier du catalogue traditionnel. Si c'était la cas > une erreur invalidante dans le fsroot tree laisse peu de chance pour que le volume qui en dépend puisse être remonté.

  • Je relève une agaçante inconsistance dans le compte rendu terminal :
    Bloc de code:
    The volume /dev/rdisk2s1 could not be verified completely
    File system check exit code is 0
    Le volume /dev/rdisk2s1 n'a pas pu être vérifié complètement > Le code de sortie de la vérification du système de fichiers est 0 (0 erreurs) --> car comment peut-on déclarer qu'il n'y a aucune erreur puisqu'une erreur radicale a invalidé la vérification du fsroot tree sans qu'elle puisse être réparée ?

En résumé : je ne peux que te conseiller une combinaison de patience et d'espérance --> re-démarre régulièrement sur l'OS que tu as installé sur ton DDE > et répète l'opération de déverrouillage du volume chiffré.

  • Je conjecture que le déverrouillage s'effectue bien (il n'y a pas de raison que ton mot-de-passe ne soit pas reçu) > mais que c'est l'étape immédiatement suivante qui bloque. En effet, c'est le service de l'OS démarré diskarbitrationd (daemon d'abitrage des disques) qui opère la probation des systèmes de fichiers avant de passer au kernel (le noyau du Système démarré) la tâche de monter le volume. C'est donc le daemon diskarbitrationd qui doit rejeter la probation du système de fichiers APFS (à cause des erreurs dans le fsroot tree) et bloquer le montage du volume par le kernel.

=> une fois ton volume déverrouillé (mais non monté) > répète des S.O.S. dessus dans l'espoir qu'une correction puisse intervenir qui ferait passer la probation au système de fichiers et permettrait le remontage du volume. Tu peux aussi sélectionner le volume (sans doute grisé car non monté) et utiliser le bouton : "Monter" pour voir si la commande est suivie.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Heisenberg92100
Salut Heisenberg

Je m'immisce dans ton fil dans un rôle de commentateur.

L'opération de vérification / réparation que tu as lancée porte sur la structure du système de fichiers APFS dont dépend aussi bien le Container disk2 global que le volume Macintosh HD disk2s1.

Ce nouveau système de fichiers APFS est extraordinairement non documenté jusqu'à présent. Tu obtiens une erreur sur le composant suivant de sa structure :
Bloc de code:
fsroot tree is invalid

« l'arbre-racine du système de fichiers est invalide » (si je puis risquer cette traduction). Cette désignation me fait penser au traditionnel : « B-tree catalog » dans le système de fichiers JHFS+ --> à savoir, le fichier gérant l'adressage aux fichiers (considérés métaphoriquement comme des feuilles terminales) via une arborescence partant du point-de-montage considéré comme la racine (root) > et allant aux données terminales par une série de dérivations en embranchements (nodes) portant des clés (keys) numériques.

Dans l'ancien système de fichiers JHFS+ > des erreurs de nœuds (nodes) invalidaient toute l'arborescence qui en dérivait > et par là rendait impossible l'accès aux données terminales qui en relevaient pour lecture > édition > ajout > remplacement > suppression. Ces erreurs dans le catalogue B-tree était invalidantes (radicales) - le catalogue étant le noyau du système de fichiers.

Je ne sais pas si l'analogie verbale « B-tree catalog » --> « fsroot tree » permet de voir dans le fsroot tree l'héritier du catalogue traditionnel. Si c'était la cas > une erreur invalidante dans le fsroot tree laisse peu de chance pour que le volume qui en dépend puisse être remonté.

  • Je relève une agaçante inconsistance dans le compte rendu terminal :
    Bloc de code:
    The volume /dev/rdisk2s1 could not be verified completely
    File system check exit code is 0
    Le volume /dev/rdisk2s1 n'a pas pu être vérifié complètement > Le code de sortie de la vérification du système de fichiers est 0 (0 erreurs) --> car comment peut-on déclarer qu'il n'y a aucune erreur puisqu'une erreur radicale a invalidé la vérification du fsroot tree sans qu'elle puisse être réparée ?

En résumé : je ne peux que te conseiller une combinaison de patience et d'espérance --> re-démarre régulièrement sur l'OS que tu as installé sur ton DDE > et répète l'opération de déverrouillage du volume chiffré.

  • Je conjecture que le déverrouillage s'effectue bien (il n'y a pas de raison que ton mot-de-passe ne soit pas reçu) > mais que c'est l'étape immédiatement suivante qui bloque. En effet, c'est le service de l'OS démarré diskarbitrationd > qui opère la probation des systèmes de fichiers avant de passer au kernel (le noyau du Système démarré) la tâche de monter le volume. C'est donc le daemon diskarbitrationd qui doit rejeter la probation du système de fichiers APFS (à cause des erreurs dans le fsroot tree) et bloquer le montage du volume par le kernel.

=> une fois ton volume déverrouillé (mais non monté) > répète des S.O.S. dessus dans l'espoir qu'une correction puisse intervenir qui ferait passer la probation au système de fichiers et permettrait le remontage du volume.
Pas mieux. As-tu une sauvegarde Time Machine ou autre?
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Heisenberg92100
Pas mieux. As-tu une sauvegarde Time Machine ou autre?

Non malheureusement, je n'ai aucune sauvegarde et dire qu'il y a toutes les photos de la naissance de mes enfants jusqu'à maintenant :-(

Salut Heisenberg

Je m'immisce dans ton fil dans un rôle de commentateur.

L'opération de vérification / réparation que tu as lancée porte sur la structure du système de fichiers APFS dont dépend aussi bien le Container disk2 global que le volume Macintosh HD disk2s1.

Ce nouveau système de fichiers APFS est extraordinairement non documenté jusqu'à présent. Tu obtiens une erreur sur le composant suivant de sa structure :
Bloc de code:
fsroot tree is invalid

« l'arbre-racine du système de fichiers est invalide » (si je puis risquer cette traduction). Cette désignation me fait penser au traditionnel : « B-tree catalog » dans le système de fichiers JHFS+ --> à savoir, le fichier gérant l'adressage aux fichiers (considérés métaphoriquement comme des feuilles terminales) via une arborescence partant du point-de-montage considéré comme la racine (root) > et allant aux données terminales par une série de dérivations en embranchements (nodes) portant des clés (keys) numériques.

Dans l'ancien système de fichiers JHFS+ > des erreurs de nœuds (nodes) invalidaient toute l'arborescence qui en dérivait > et par là rendait impossible l'accès aux données terminales qui en relevaient pour lecture > édition > ajout > remplacement > suppression. Ces erreurs dans le catalogue B-tree était invalidantes (radicales) - le catalogue étant le noyau du système de fichiers.

Je ne sais pas si l'analogie verbale « B-tree catalog » --> « fsroot tree » permet de voir dans le fsroot tree l'héritier du catalogue traditionnel. Si c'était la cas > une erreur invalidante dans le fsroot tree laisse peu de chance pour que le volume qui en dépend puisse être remonté.

  • Je relève une agaçante inconsistance dans le compte rendu terminal :
    Bloc de code:
    The volume /dev/rdisk2s1 could not be verified completely
    File system check exit code is 0
    Le volume /dev/rdisk2s1 n'a pas pu être vérifié complètement > Le code de sortie de la vérification du système de fichiers est 0 (0 erreurs) --> car comment peut-on déclarer qu'il n'y a aucune erreur puisqu'une erreur radicale a invalidé la vérification du fsroot tree sans qu'elle puisse être réparée ?

En résumé : je ne peux que te conseiller une combinaison de patience et d'espérance --> re-démarre régulièrement sur l'OS que tu as installé sur ton DDE > et répète l'opération de déverrouillage du volume chiffré.

  • Je conjecture que le déverrouillage s'effectue bien (il n'y a pas de raison que ton mot-de-passe ne soit pas reçu) > mais que c'est l'étape immédiatement suivante qui bloque. En effet, c'est le service de l'OS démarré diskarbitrationd (daemon d'abitrage des disques) qui opère la probation des systèmes de fichiers avant de passer au kernel (le noyau du Système démarré) la tâche de monter le volume. C'est donc le daemon diskarbitrationd qui doit rejeter la probation du système de fichiers APFS (à cause des erreurs dans le fsroot tree) et bloquer le montage du volume par le kernel.

=> une fois ton volume déverrouillé (mais non monté) > répète des S.O.S. dessus dans l'espoir qu'une correction puisse intervenir qui ferait passer la probation au système de fichiers et permettrait le remontage du volume. Tu peux aussi sélectionner le volume (sans doute grisé car non monté) et utiliser le bouton : "Monter" pour voir si la commande est suivie.

Merci pour ces infos, malheureusement, lorsque High Sierra demarre, il me demande mon password et il ne le prend jamais jusqu'à la disparition de la fenetre.
Et sur le Terminal en mode Recovery, impossible de monter le Macintosh HD.

N'y a t il pas une méthode forcée pour le mount du Macintosh HD ?
 
Dernière édition par un modérateur:
C'est là que ça se corse, car tu es en clavier qwerty
Donc tu vas taper :
fsck°apfs )y =dev=diskés&

Ça devrait afficher à l'écran :
fsck_apfs -y /dev/disk2s1

Si ok tu valides par la touche "Entrée"
 
  • J’aime
Réactions: Heisenberg92100
Tente de faire :
;ount )uw
fsck°apfs )y =dev=diskés&


Ça devrait afficher à l'écran :
mount -uw
fsck_apfs -y /dev/disk2s1
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Heisenberg92100