MacBook Pro Mon MacBook ne démarre pas en mode sans échec
- Créateur du sujet Quent27
- Date de début
@macomaniac @jeanjd63 vous pouvez prendre le relais ... Pour faire simple il a installer le Filevault , il faut juste réparer son volume qui n est pas monte .
@Quent27 deux spécialistes du terminal vont prendre le relais comme il faut que je dorme ! mais t inquiète pas , c est juste des commandes a passer sur le terminal et tout fonctionnera ... je suivrais le post
@Quent27 deux spécialistes du terminal vont prendre le relais comme il faut que je dorme ! mais t inquiète pas , c est juste des commandes a passer sur le terminal et tout fonctionnera ... je suivrais le post
D
Deleted member 1099514
Invité
Salut @Quent27
Désolé, mais tes photos sont illisibles.
Depuis le mode Recovery/Terminal, tu vas taper la commande :
diskutil list
Tu fais un copier du résultat, tu quittes le terminal et dans le menu à 4 choix, tu sélectionnes :
"Obtenir de l'aide".
Là tu est sur safari et tu peux accéder au forum et donner les résultats par copier entre balises Code :
Ensuite tu recommences avec la commande :
diskutil cs list
Autre précision importante. Quelle est l'année de fabrication de ton Mac et quel est le modèle exact?
Si tu ne le sais pas, dans le terminal tu peux taper la commande :
system_profiler SPHardwareDataType
ou
sysctl hw.model
Désolé, mais tes photos sont illisibles.
Depuis le mode Recovery/Terminal, tu vas taper la commande :
diskutil list
Tu fais un copier du résultat, tu quittes le terminal et dans le menu à 4 choix, tu sélectionnes :
"Obtenir de l'aide".
Là tu est sur safari et tu peux accéder au forum et donner les résultats par copier entre balises Code :
Ensuite tu recommences avec la commande :
diskutil cs list
Autre précision importante. Quelle est l'année de fabrication de ton Mac et quel est le modèle exact?
Si tu ne le sais pas, dans le terminal tu peux taper la commande :
system_profiler SPHardwareDataType
ou
sysctl hw.model
Dernière édition par un modérateur:
M
Membre supprimé 1060554
Invité
les-z-amisninkasi devrait être « plus » prudent : ce n'est pas en vain qu'on en appelle aux services de Jean
ou de mézigue 
En ce qui concerne ma pomme : on se voit infliger une « épistémologie » en sus (sous forme de laïus en bonne et due forme).
Allez hop ! Quand un format CoreStorage se trouve inscrit sur une partition de disque (comme ici la disk0s2) > partition qui était déjà gérée par un système de fichiers assurant la montée d'un volume sur ses blocs > système de fichiers résidant sur l'en-tête de la partition en question > alors il s'effectue un processus sournois dans les « bas-fonds » de la partition.
Comme l'en-tête de la partition est déjà occupé par les fichiers du système de fichiers JHFS+ > lesquels y sont ancrés à demeure > la seule localisation disponible pour les fichiers du CoreStorage est alors la queue de partition, toujours retaillable. C'est sur les blocs de fin de partition, donc, que les « headers » (les en-têtes logiques) du dispositif CoreStorage vont se trouver inscrits, en cas de partition déjà formatée.
Pour décrire les choses de manière imagée > ces « headers » du CoreStorage vont faire glisser des « couches logiques » entre le système de fichiers JHFS+ en place (et le volume qu'il monte) > et le container de blocs bruts de la partition. Pour résumer à l'essentiel : 2 couches logiques principales distribuées en superposition -->
- importé directement sur les blocs du container de la partition : un Physical Volume > qui re-configure les blocs de la partition comme constituant un Disque Dur Virtuel ;
- exporté secondairement à partir du Physical Volume : un Logical Volume > qui constitue une redondance logique du Physical Volume : un Disque Miroir Virtuel.
=> par suite de cet intercalement logique > le système de fichiers JHFS+ n'est plus représenté comme ancré sur l'en-tête brut de la partition > mais comme amarré à un « dev node » (un nœud d'appareil) du Logical Volume --> il est donc re-configuré comme une « tierce instance » : il gère la montée en volume de l'espace logique du Logical Volume > lequel est intrinsèquement un espace-miroir du Physical Volume ou disque dur émulé sur le container de la partition.
C'est ce dispositif inouï (créé à l'époque de l'OS «Lion 10.7») qui permet seul le mécanisme logique du chiffrement. Car il devient possible d'avoir un espace logique du Physical Volume entièrement chiffré en permanence > par rapport auquel le Logical Volume constitue un espace-miroir entièrement déchiffré (un traducteur assurant en permanence la conversion d'un espace logique à l'autre). Aussi > le système de fichiers résidant sur le Logical Volume > gère en permanence des fichiers lisibles > tandis que le mécanisme de traduction Logical Volume <=> Physical Volume assure la conversion en écritures chiffrées.
----------
Ce laïus exposé > on comprend un peu mieux pourquoi, systématiquement, le Logical Volume d'un CoreStorage se trouve identifié comme un device (appareil) de second ordre : un disk1 par rapport au device disk0 du disque physique. Car si le Physical Volume équivaut à la partition disk0s2 redéfinie logiquement comme Disque Dur Virtuel > le Logical Volume, en tant que Disque-Miroir exporté (redondance logique), constitue l'équivalent d'un « second disque » logique : d'un disque « jumeau » > qui est donc naturellement identifié comme un disk1 (ou un disk17 dans la numérotation assez spéciale des devices en cas de démarrage en mode Recovery).
Si l'on veut alors lancer une opération de réparation (à supposer bien sûr le Logical Volume déverrouillé au préalable s'il y a chiffrement «FileVault» > et à supposer encore un démarrage sur un Système indépendant de l'OS comme le Recovey OS) --> alors il y a 2 niveaux d'opérations possibles :
- a) une commande de la forme :
va adresser spécifiquement le Logical Volume du CoreStorage en tant que Disque-Miroir Redondant de second ordre --> c'est donc une vérification / réparation des structures logiques intrinsèques du CoreStorage qui va avoir lieu (à savoir : s'il y bien adéquation logique Logical Volume exporté / Physical Volume importé...) ;
- b) une commande de la forme :
va non seulement adresser le Logical Volume du CoreStorage (pour vérifier / réparer le dispositif de redondance Logical Volume / Physical Volume) > mais va adresser le système de fichiers JHFS+ qui est l'hôte-résident du Logical Volume --> il va donc y avoir en seconde instance une vérification d'intégrité classique du système de fichiers (catalogue etc.) > càd. de sa capacité à gérer sans erreurs l'espace logique du Logical Volume pour le monter en volume classique.
Bloc de code:
diskutil repairDisk /dev/disk17- b) une commande de la forme :
Bloc de code:
diskutil repairVolume /dev/disk17Dans le cas spécifique de Quent27 > tel que montré par ses captures initiales d'affichages dans l'interface de l'«Utilitaire de Disque» -->
- le code de sortie de la vérification du « système de stockage CoreStorage » est 0 = sans erreur ;
- le code de sortie de la vérification du « système de fichiers JHFS+ » est 8 = erreurs irréparables.
=> en résumé : le « magasinage du noyau » (dispositif logique du CoreStorage) est sans erreurs > c'est le système de fichiers JHFS+ terminal qui est corrompu. L'erreur paraît survenir sur la vérification du fichier du catalogue (catalogue B-tree) > qui permet l'adressage des fichiers de données.
Dernière édition par un modérateur:
Voici après toute les manip réaliser
Bloc de code:
-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 499.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/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 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +5.2 MB disk2
/dev/disk3 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk3
/dev/disk4 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk4
/dev/disk5 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk5
/dev/disk6 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk6
/dev/disk7 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk7
/dev/disk8 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk8
/dev/disk9 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk9
/dev/disk10 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk10
/dev/disk11 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB 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 +524.3 KB disk13
/dev/disk14 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk14
/dev/disk15 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk15
/dev/disk16 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk16
/dev/disk17 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Macintosh HD +498.9 GB disk17
Logical Volume on disk0s2
314CF9D0-2E5C-46E5-BE90-5664B25603E1
Unlocked Encrypted
-bash-3.2# diskutil repair volume/
diskutil: did not recognize verb "repair"; type "diskutil" for a list
-bash-3.2# diskutil repair volume
diskutil: did not recognize verb "repair"; type "diskutil" for a list
-bash-3.2# diskutil repairDisk/dev/disk17
diskutil: did not recognize verb "repairDisk/dev/disk17"; type "diskutil" for a list
-bash-3.2# diskutil repairvolume/
diskutil: did not recognize verb "repairvolume/"; type "diskutil" for a list
-bash-3.2# diskutil repairvolume /
Error starting file system repair for disk1s1 OS X Base System: Unable to unmount volume for repair (-69673)
-bash-3.2# diskutil repairvolume/dev/disk17 /
diskutil: did not recognize verb "repairvolume/dev/disk17"; type "diskutil" for a list
-bash-3.2# diskutil repairDisk /dev/disk17
You cannot specify a CoreStorage logical volume (and a logical volume should not have a partition map)
-bash-3.2# diskutil repairVolume /dev/disk17
Started file system repair on disk17 Macintosh HD
Verifying storage system
Checking volume
disk0s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
Logical Volume Group 3EB6557D-CB6D-4373-90A4-160C49BEF645 on 1 device
disk0s2: Scan for Metadata Volume
Logical Volume Group has a 24 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 6CE6625B-33BD-4DD0-8645-993C5EB75731
Load and verify 314CF9D0-2E5C-46E5-BE90-5664B25603E1
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 3EB6557D-CB6D-4373-90A4-160C49BEF645 appears to be OK
Storage system check exit code is 0
Repairing file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
The volume Macintosh HD could not be verified completely
File system check exit code is 8
Updating boot support partitions for the volume as required
Error: -69845: File system verify or repair failed
Underlying error: 8: Exec format error
-bash-3.2#
D
Deleted member 1099514
Invité
Que te renvoie un :
diskutil cs list
Tu peux tenter un :
diskutil cs decryptVolume 3EB6557D-CB6D-4373-90A4-160C49BEF645
diskutil cs list
Tu peux tenter un :
diskutil cs decryptVolume 3EB6557D-CB6D-4373-90A4-160C49BEF645
Sujets similaires
MacBook Pro
MacBook Pro 15" mi-2014 qui ne démarre plus
