D
Impossible de réparer disque !
- Créateur du sujet DjTronico
- Date de début
Le formatage a fonctionné. Il reste 4h30 avant la fin de la restauration. Je te tiens informé.
D
Deleted member 1099514
Invité
J'en profite pour préciser un truc : quand vous démarrez sur la partition Recovery HD, vous êtes toujours sur votre disque, même si plus sur le volume système. D'où la nécessité de passer par la restauration internet qui n'est pas dépendante du disque.
Donc Recovery HD (cmd r) c'est bien pour les réparations simples, mais pour les trucs compliqués comme les erreurs sur le schéma de partition, il faut en passer par un système externe ou la restauration internet (cmd alt r).
Une remarque sur les captures d'écran : quand on a un problème avec le dd interne, il est inutile de laisser connecter d'autres volumes si ceux-ci ne participent pas directement au travail de réparation. Donc le disque 2 To WD n'avait rien à faire là.
Donc Recovery HD (cmd r) c'est bien pour les réparations simples, mais pour les trucs compliqués comme les erreurs sur le schéma de partition, il faut en passer par un système externe ou la restauration internet (cmd alt r).
Une remarque sur les captures d'écran : quand on a un problème avec le dd interne, il est inutile de laisser connecter d'autres volumes si ceux-ci ne participent pas directement au travail de réparation. Donc le disque 2 To WD n'avait rien à faire là.
C'est avec plaisir que je vous écrit ce message sur mon MBA ! La restauration a bien fonctionnée. C'est nickel.
Merci à tous pour votre aide, en particulier à jeanjd63. J'aurais jamais cru avoir autant de réponse un dimanche...
Je pense que c'était un problème de détection de partitions, mais quoi exactement et surtout pourquoi ???
Pour répondre à Moonwalker, mon disque WD contient, entre autre, une partition dédiée aux sauvegardes TimeMachine, d'ou sa présence sur mes screenshots.
Merci à tous pour votre aide, en particulier à jeanjd63. J'aurais jamais cru avoir autant de réponse un dimanche...
Je pense que c'était un problème de détection de partitions, mais quoi exactement et surtout pourquoi ???
Pour répondre à Moonwalker, mon disque WD contient, entre autre, une partition dédiée aux sauvegardes TimeMachine, d'ou sa présence sur mes screenshots.
D
Deleted member 1099514
Invité
Super.
Tu pourras passer ton post en "Résolu"
Et bonne fête de la musique.
Il faut vérifier que la partition de Recovery existe bien.
Peux-tu donner le retour de la commande :
diskutil list
@+
Tu pourras passer ton post en "Résolu"
Et bonne fête de la musique.
Il faut vérifier que la partition de Recovery existe bien.
Peux-tu donner le retour de la commande :
diskutil list
@+
Dernière édition par un modérateur:
Oui, mais avec la nervosité et la fatigue, on n'est pas à l'abris d'une mauvaise manœuvre. J'ai déjà vu le cas. A bout de ses tentatives de réparation, la personne a effacé le mauvais disque.
Mais c'est juste une remarque en passant car je vois souvent des disques branchés sur les captures qui ne devraient pas se trouver là.
/dev/disk0Super.
Tu pourras passer ton post en "Résolu"
Et bonne fête de la musique.
Il faut vérifier que la partition de Recovery existe bien.
Peux-tu donner le retour de la commande :
diskutil list
@+
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 121.0 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *2.0 TB disk1
1: Windows_NTFS Données 692.6 GB disk1s1
2: Apple_HFS TimeMachine 804.5 GB disk1s2
3: Windows_NTFS Photos 503.3 GB disk1s3
D
Deleted member 1099514
Invité
Donc pas de Recovery HD.
Pour ma recréer il faut suivre ceci :
http://www.macplanete.com/astuces/14067/yosemite-recovery-mac
@+
Pour ma recréer il faut suivre ceci :
http://www.macplanete.com/astuces/14067/yosemite-recovery-mac
@+
M
Membre supprimé 1060554
Invité
Lorsque l'aimable Locke 
m'appela hier à la rescousse (à 17H 13') :
DJTronico avait déjà (à 15H 30') opéré le re-partitionnement de son SSD et lancé la récupération de sa sauvegarde «TimeMachine» à partir d'un démarrage par internet sur la «Recovery-on-Line» - dont s'est ensuivi un succès de la re-création du volume /dev/disk0s2 et de la ré-installation du Système avec données. Moins évidemment la partition de récupération du disque : «Recovery HD» "sucrée" par l'opération de re-partitionnement et qu'une récupération de «TimeMachine» est bien incapable de re-créer (mais le lien donné au message #30 devrait permettre cette reconstitution - à condition bien entendu de commencer par re-télécharger depuis l'AppStore l'installateur de la version actuelle de «Yosemite» requis par le script du «Recovery Partition Creator»).
[Je signale, pour les amateurs d'entomologie logicielle, que l'auteur de cette application, comme je m'en suis fait le pari matutinal, n'a pas fabriqué un programme ad hoc pour permettre la recréation d'une partition de récupération à partir d'un installateur Install OS X Yosemite.app. Comme on peut le vérifier en inspectant le contenu du paquet, à l'adresse : Recovery Partition Creator 3.8.app/Contents/Resources/dmtest --> il a carrément embarqué le programme : dmtest dans les ressources de son application - programme précieux créé par Apple à l'époque de l'OS «Lion 10.7» pour permettre cette opération et embarqué à l'époque dans le RecoveryHDUpdate.dmg (encore re-téléchargeable sur la page : ☞Mise à jour de Récupération Lion☜) à partir du paquet duquel on peut toujours l'extraire.]
Mais trêve de balivernes. Appelé donc par Locke à la rescousse pour tenir le rôle des Carabiniers d'Offenbach qui pointent une fois la victoire acquise en se joignant à la Fête de la Musique finale de cette opérette - je me retrouve dans cette position d'épigone que j'affectionne entre toutes pour sa parfaite gratuité d'un point de vue pragmatique (mais, comme relevé en son temps par Hegel avec son image de la «Chouette de Minerve» qui «prend son envol le soir» lorsqu'une journée de l'Esprit s'est achevée, propice à la liberté théorique - pour ne pas dire philosophique - dans le crépuscule du matin suivant)...
Dans cette position de rétrospection, je vois que Jean a très méthodiquement dirigé la manœuvre en proposant une réparation du volume de l'OS en mode Single User, puis un reformatage via la «Recovery HD» suivi d'une information sur l'éventuel format CoreStorage qui aurait verrouillé la partition /dev/disk0s2, et enfin un re-partitionnement du disque global via un démarrage par internet sur le disque d'une «Recovery-on-Line» - solution qui a marché. Et je relève que Moon m'a lui-même précédé dans la position de chanteur rétrospectif de Péan (situation dont les «Odes Triomphales» de Pindare illustrent la fonction esthétique) - en rappelant la différence de puissance d'intervention selon qu'on démarre sur le système auxiliaire d'un même disque ou sur un disque séparé de celui qu'on veut réparer.
Me voici donc cantonné à venir gribouiller dans le pied-de-page de ce fil une tortueuse glose de prosateur.
Je relève que dans la capture inaugurale (malheureusement très incomplète : message #1) de la fenêtre de l'«Utilitaire de Disque» lancé avec l'option "Réparer le disque" après démarrage sur la «Recovery HD» - voici ce qui était mentionné :
Vérification des partitions du volume physique Core Storage
Réparation du système de stockage
Checking volume
disk0s2 : scan for Volumes Headers
Invalid Volume Header ⭕︎ 0: invalid field value
Invalid Volume Header ⭕︎ 120473067008: unsupported format
disk0s2 did not complete formatting as a Core Storage volume
Le code de sortie de la vérification du système de stockage est 1
Problèmes rencontrés lors de la réparation de la carte de partition
Erreur : ce disque doit être réparé. Cliquer sur Réparer le disque
☞ Ces informations révèlent qu'un format CoreStorage était bien greffé originellement sur la partition /dev/disk0s2 de l'OS (cas fréquemment suscité par l'installateur de «Yosemite»). Ce format encapsule le système de fichiers jhfs+ de la partition concernée dans un "emballage" logique à 3 instances : conversion de la partition au statut de Disque Physique Virtuel (Physical Volume) ; définition d'une instance médiane de pilotage = Famille de Volumes Logique (Logical Volume Family) ; exportation d'un Volume Logique (Logical Volume).
La capture de l'«Utilitaire de Disque» montrait également qu'aucun volume n'était rejeté par le format CoreStorage (pas plus en position "monté" que "démonté") --> il était donc présumable que le couple solidaire : Famille de Volumes Logiques / Volume Logique avait tout bonnement "sauté" pour ne laisser en place que l'instance primaire : le Physical Volume (Disque Physique Virtuel) équivalant à la conversion logique de base de la partition /dev/disk0s2. J'ai déjà rencontré dans un fil assez récent un tel type d'accident : un CoreStorage dont l'architecture se trouve "décapitée" pour ne laisser en place que l'instance du Physical Volume.
Mais dans le cas évoqué, la commande : diskutil cs list (judicieusement préconisée ici par Jean) renvoyait un : Core Storage Logical Volume Groups : 1 found avec affichage de la seule entrée de tableau répertoriant le Physical Volume célibataire. Cette situation permettait, soit une commande de destruction du CoreStorage recréant un volume standard (vierge) jhfs+, soit une commande de ré-exportation d'un Volume Logique à partir du Physical Volume intact.
Dans le cas présent, le retour de commande : "No CoreStorage logical volume groups found" signale nonobstant une situation plus extraordinaire : un CoreStorage réduit à l'instance primaire du Physical Volume (existence attestée par la mention dans l'«Utilitaire de Disque» : Vérification des partitions du volume physique Core Storage) qui, néanmoins, ne se trouve pas reconnu comme validement existant par le programme diskutil invoqué.
Situation des plus remarquable : une instance existante non reconnue dans son existence logique. Car, si je scrute le message d'erreur donné par l'«Utilitaire de Disque» :
Invalid Volume Header ⭕︎ 0: invalid field value
Invalid Volume Header ⭕︎ 120473067008: unsupported format
disk0s2 did not complete formatting as a Core Storage volume
les "Volume Headers" pointés ("en-tête") correspondent à ce que l'instance médiane de la Famille de Volumes Logiques met en place sur le Disque Physique Virtuel pré-existant (le Physical Volume) afin de rejeter l'instance de sortie du Logical Volume. Le programme diskutil se montrait capable de déceler la présence de tels "Headers", mais dans un tel état de corruption qu'aucun Volume Logique ne pouvait être exporté. Si l'aimable assistance a bien voulu suivre cette argutie glosatrice de l'épigone macomaniac, il est clair que ce qui était pointé comme invalide par là était un composant de seconde instance du Groupe de Volumes Logiques : Core Storage, et nullement l'instance primaire du Physical Volume (Disque Physique Virtuel) inaffectée, intrinsèquement, par la corruption logique de la Famille de Volumes Logiques. Il s'ensuit que la commande : diskutil cs list aurait dû, logiquement, retourner le constat d'existence (avec son UUID) d'un Groupe de Volumes Logiques réduit à son instance primaire : le Physical Volume.
Or tout s'est passé comme_si la corruption de l'instance seconde : la Logical Volume Family avait, par un effet "récursif", invalidé l'existence de la prime instance du Physical Volume, et par là supprimé carrément le Groupe de Volumes Logiques.
Je trouve extrêment inquiétant ce phénomène d'erreur "récursive" ("rétrograde") dans un format CoreStorage. Car je me figurais qu'une invalidation logique frappant le Volume Logique n'impliquait que l'autre instance solidaire dans le couple : la Famille de Volumes Logiques - sans pouvoir avoir de répercussion rétrograde sur l'instance primaire constitutive du "socle logique" du CoreStorage. Une erreur sur le seul binôme : Logical Volume Family / Logical Volume, préservant l'instance primaire du Physical Volume, permet en effet un adressage de ce qui tient lieu de Disque Physique Virtuel afin de re-créer un Volume Logique. Or là, suite à cet effet "récursif" sur le Physical Volume même, le CoreStorage tout entier cesse de pouvoir être "adressé" - et pourtant il existe toujours : la preuve, il rend le reformatage de la partition /dev/disk0s2 impossible (preuve que le CoreStorage pèse toujours sur la partition en la verrouillant).
Cas extraordinaire : l'encapsulage par le Physical Volume existe bien, mais sans que cette existence ait une valeur logique reconnaissable. Je trouve ce dérapage tout à fait inquiétant. Car enfin, comme l'a montré l'installateur de «Yosemite» qui manifestement possède l'instruction subreptice de faire "pulluler" ce format sur le disque des Macs à l'insu du "plein gré" des utilisateurs, ce format paraît avoir vent en poupe pour les ingénieurs de la --> n'est-il pas aussi "résistant" qu'on pourrait l'escompter ? Est-il susceptible de corruptions logiques récursives qui créent une situation de blocage absolu aussi longtemps qu'on ne re-partitionne pas le disque entier à partir du démarrage sur un disque totalement indépendant ? N'est-ce pas là un phénomène contredisant la gestion élastique que ce format paraît supporter sur le papier ?
☞ ce cas me rend, je l'avoue, extrêmement perplexe (et je n'ai pas la plus petite idée des causes qui ont induit cette corruption logique récursive du CoreStorage)...
m'appela hier à la rescousse (à 17H 13') :DJTronico
avait déjà (à 15H 30') opéré le re-partitionnement de son SSD et lancé la récupération de sa sauvegarde «TimeMachine» à partir d'un démarrage par internet sur la «Recovery-on-Line» - dont s'est ensuivi un succès de la re-création du volume /dev/disk0s2 et de la ré-installation du Système avec données. Moins évidemment la partition de récupération du disque : «Recovery HD» "sucrée" par l'opération de re-partitionnement et qu'une récupération de «TimeMachine» est bien incapable de re-créer (mais le lien donné au message #30 devrait permettre cette reconstitution - à condition bien entendu de commencer par re-télécharger depuis l'AppStore l'installateur de la version actuelle de «Yosemite» requis par le script du «Recovery Partition Creator»).[Je signale, pour les amateurs d'entomologie logicielle, que l'auteur de cette application, comme je m'en suis fait le pari matutinal, n'a pas fabriqué un programme ad hoc pour permettre la recréation d'une partition de récupération à partir d'un installateur Install OS X Yosemite.app. Comme on peut le vérifier en inspectant le contenu du paquet, à l'adresse : Recovery Partition Creator 3.8.app/Contents/Resources/dmtest --> il a carrément embarqué le programme : dmtest dans les ressources de son application - programme précieux créé par Apple à l'époque de l'OS «Lion 10.7» pour permettre cette opération et embarqué à l'époque dans le RecoveryHDUpdate.dmg (encore re-téléchargeable sur la page : ☞Mise à jour de Récupération Lion☜) à partir du paquet duquel on peut toujours l'extraire.]
Mais trêve de balivernes. Appelé donc par Locke à la rescousse pour tenir le rôle des Carabiniers d'Offenbach qui pointent une fois la victoire acquise en se joignant à la Fête de la Musique finale de cette opérette - je me retrouve dans cette position d'épigone que j'affectionne entre toutes pour sa parfaite gratuité d'un point de vue pragmatique (mais, comme relevé en son temps par Hegel avec son image de la «Chouette de Minerve» qui «prend son envol le soir» lorsqu'une journée de l'Esprit s'est achevée, propice à la liberté théorique - pour ne pas dire philosophique - dans le crépuscule du matin suivant)...
Dans cette position de rétrospection, je vois que Jean
a très méthodiquement dirigé la manœuvre en proposant une réparation du volume de l'OS en mode Single User, puis un reformatage via la «Recovery HD» suivi d'une information sur l'éventuel format CoreStorage qui aurait verrouillé la partition /dev/disk0s2, et enfin un re-partitionnement du disque global via un démarrage par internet sur le disque d'une «Recovery-on-Line» - solution qui a marché. Et je relève que Moon m'a lui-même précédé dans la position de chanteur rétrospectif de Péan (situation dont les «Odes Triomphales» de Pindare illustrent la fonction esthétique) - en rappelant la différence de puissance d'intervention selon qu'on démarre sur le système auxiliaire d'un même disque ou sur un disque séparé de celui qu'on veut réparer. Me voici donc cantonné à venir gribouiller dans le pied-de-page de ce fil une tortueuse glose de prosateur.
♑︎
Je relève que dans la capture inaugurale (malheureusement très incomplète : message #1) de la fenêtre de l'«Utilitaire de Disque» lancé avec l'option "Réparer le disque" après démarrage sur la «Recovery HD» - voici ce qui était mentionné :
Vérification des partitions du volume physique Core Storage
Réparation du système de stockage
Checking volume
disk0s2 : scan for Volumes Headers
Invalid Volume Header ⭕︎ 0: invalid field value
Invalid Volume Header ⭕︎ 120473067008: unsupported format
disk0s2 did not complete formatting as a Core Storage volume
Le code de sortie de la vérification du système de stockage est 1
Problèmes rencontrés lors de la réparation de la carte de partition
Erreur : ce disque doit être réparé. Cliquer sur Réparer le disque
☞ Ces informations révèlent qu'un format CoreStorage était bien greffé originellement sur la partition /dev/disk0s2 de l'OS (cas fréquemment suscité par l'installateur de «Yosemite»). Ce format encapsule le système de fichiers jhfs+ de la partition concernée dans un "emballage" logique à 3 instances : conversion de la partition au statut de Disque Physique Virtuel (Physical Volume) ; définition d'une instance médiane de pilotage = Famille de Volumes Logique (Logical Volume Family) ; exportation d'un Volume Logique (Logical Volume).
La capture de l'«Utilitaire de Disque» montrait également qu'aucun volume n'était rejeté par le format CoreStorage (pas plus en position "monté" que "démonté") --> il était donc présumable que le couple solidaire : Famille de Volumes Logiques / Volume Logique avait tout bonnement "sauté" pour ne laisser en place que l'instance primaire : le Physical Volume (Disque Physique Virtuel) équivalant à la conversion logique de base de la partition /dev/disk0s2. J'ai déjà rencontré dans un fil assez récent un tel type d'accident : un CoreStorage dont l'architecture se trouve "décapitée" pour ne laisser en place que l'instance du Physical Volume.
Mais dans le cas évoqué, la commande : diskutil cs list (judicieusement préconisée ici par Jean) renvoyait un : Core Storage Logical Volume Groups : 1 found avec affichage de la seule entrée de tableau répertoriant le Physical Volume célibataire. Cette situation permettait, soit une commande de destruction du CoreStorage recréant un volume standard (vierge) jhfs+, soit une commande de ré-exportation d'un Volume Logique à partir du Physical Volume intact.
Dans le cas présent, le retour de commande : "No CoreStorage logical volume groups found" signale nonobstant une situation plus extraordinaire : un CoreStorage réduit à l'instance primaire du Physical Volume (existence attestée par la mention dans l'«Utilitaire de Disque» : Vérification des partitions du volume physique Core Storage) qui, néanmoins, ne se trouve pas reconnu comme validement existant par le programme diskutil invoqué.
Situation des plus remarquable : une instance existante non reconnue dans son existence logique. Car, si je scrute le message d'erreur donné par l'«Utilitaire de Disque» :
Invalid Volume Header ⭕︎ 0: invalid field value
Invalid Volume Header ⭕︎ 120473067008: unsupported format
disk0s2 did not complete formatting as a Core Storage volume
les "Volume Headers" pointés ("en-tête") correspondent à ce que l'instance médiane de la Famille de Volumes Logiques met en place sur le Disque Physique Virtuel pré-existant (le Physical Volume) afin de rejeter l'instance de sortie du Logical Volume. Le programme diskutil se montrait capable de déceler la présence de tels "Headers", mais dans un tel état de corruption qu'aucun Volume Logique ne pouvait être exporté. Si l'aimable assistance a bien voulu suivre cette argutie glosatrice de l'épigone macomaniac, il est clair que ce qui était pointé comme invalide par là était un composant de seconde instance du Groupe de Volumes Logiques : Core Storage, et nullement l'instance primaire du Physical Volume (Disque Physique Virtuel) inaffectée, intrinsèquement, par la corruption logique de la Famille de Volumes Logiques. Il s'ensuit que la commande : diskutil cs list aurait dû, logiquement, retourner le constat d'existence (avec son UUID) d'un Groupe de Volumes Logiques réduit à son instance primaire : le Physical Volume.
Or tout s'est passé comme_si la corruption de l'instance seconde : la Logical Volume Family avait, par un effet "récursif", invalidé l'existence de la prime instance du Physical Volume, et par là supprimé carrément le Groupe de Volumes Logiques.
Je trouve extrêment inquiétant ce phénomène d'erreur "récursive" ("rétrograde") dans un format CoreStorage. Car je me figurais qu'une invalidation logique frappant le Volume Logique n'impliquait que l'autre instance solidaire dans le couple : la Famille de Volumes Logiques - sans pouvoir avoir de répercussion rétrograde sur l'instance primaire constitutive du "socle logique" du CoreStorage. Une erreur sur le seul binôme : Logical Volume Family / Logical Volume, préservant l'instance primaire du Physical Volume, permet en effet un adressage de ce qui tient lieu de Disque Physique Virtuel afin de re-créer un Volume Logique. Or là, suite à cet effet "récursif" sur le Physical Volume même, le CoreStorage tout entier cesse de pouvoir être "adressé" - et pourtant il existe toujours : la preuve, il rend le reformatage de la partition /dev/disk0s2 impossible (preuve que le CoreStorage pèse toujours sur la partition en la verrouillant).
Cas extraordinaire : l'encapsulage par le Physical Volume existe bien, mais sans que cette existence ait une valeur logique reconnaissable. Je trouve ce dérapage tout à fait inquiétant. Car enfin, comme l'a montré l'installateur de «Yosemite» qui manifestement possède l'instruction subreptice de faire "pulluler" ce format sur le disque des Macs à l'insu du "plein gré" des utilisateurs, ce format paraît avoir vent en poupe pour les ingénieurs de la --> n'est-il pas aussi "résistant" qu'on pourrait l'escompter ? Est-il susceptible de corruptions logiques récursives qui créent une situation de blocage absolu aussi longtemps qu'on ne re-partitionne pas le disque entier à partir du démarrage sur un disque totalement indépendant ? N'est-ce pas là un phénomène contredisant la gestion élastique que ce format paraît supporter sur le papier ?
☞ ce cas me rend, je l'avoue, extrêmement perplexe (et je n'ai pas la plus petite idée des causes qui ont induit cette corruption logique récursive du CoreStorage)...
♍︎
Dernière édition par un modérateur:
Nous vous informons que si vous avez lu la réponse de Macomaniac, et que vous êtes un humain normalement constitué, vous devriez être en proie à de sérieux mots de têtes, crises d'angoisses, problemes respiratoires, convulsions.
Dans quelques rares cas extrêmes, certains lecteurs auraient même ressenti le besoin d'installer Windows 98 (peine perdue sur iPhone)
Macgénération déclare ne pas être responsable des effets causés par la lecture de ce post et recommande la lus grande prudence.
Dans quelques rares cas extrêmes, certains lecteurs auraient même ressenti le besoin d'installer Windows 98 (peine perdue sur iPhone)
Macgénération déclare ne pas être responsable des effets causés par la lecture de ce post et recommande la lus grande prudence.
D
Deleted member 1099514
Invité
Bonjour à tous ,
J’ai un iMac OS Sierra 27 mi 2010
2,8 GHz et 8gb Ram.
Il fonctionnait encore nickel hier soir et ce matin était très lent, j’ai alors redémarrer et là impossible de récupérer mon disk sur interne j’ai fait commande + R, j’arrive sur le menu mais la je n’arrive pas à restaurer mon disque , il n’y a que le DD de Mac OS X de sécurité .
Je ne sais pas quoi faire . Je voudrais juste tout réinitialiser , cela met égal de tout perdre . Merci de m’aider
J’ai un iMac OS Sierra 27 mi 2010
2,8 GHz et 8gb Ram.
Il fonctionnait encore nickel hier soir et ce matin était très lent, j’ai alors redémarrer et là impossible de récupérer mon disk sur interne j’ai fait commande + R, j’arrive sur le menu mais la je n’arrive pas à restaurer mon disque , il n’y a que le DD de Mac OS X de sécurité .
Je ne sais pas quoi faire . Je voudrais juste tout réinitialiser , cela met égal de tout perdre . Merci de m’aider
M
Membre supprimé 1060554
Invité
Bonsoir Somvilleje
Voici comment tu vas pouvoir fournir les informations de base (tuto) -->
- démarre les 2 touches ⌘R (cmd R) tenues pressées jusqu'à l'affichage d'une = démarrage sur l'OS de secours. Tu obtiens un écran affichant une fenêtre de 4 Utilitaires macOS. Va à la barre de menus supérieure de l'écran > menu : Utilitaires > sous-menu : Terminal.
Dans la fenêtre ouverte > saisis la commande informative :
et ↩︎ (presse la touche "Entrée" du clavier pour exécuter la commande)
Voici comment tu vas pouvoir poster ici ce tableau sans avoir besoin de prendre de photo -->
=> ces informations montreront la configuration logique de ton disque.
Note 1 : si tu ne peux pas poster via le Safari de la session de secours (ça arrive) --> poste une photo du tableau (à partir du commencement = le disque /dev/disk0 ou disque physique interne) - tu as un bouton : "Transférer un fichier" en bas de cette page.
Note 2 : dans la session de secours > les applications se lancent en mode "alternatif" et pas parallèle. Il faut quitter le Terminal pour lancer Safari. Vice-versa > quitter Safari pour récupérer l'écran général de la session de secours et pouvoir relancer le Terminal. Aucun redémarrage n'est requis.
Voici comment tu vas pouvoir fournir les informations de base (tuto) -->
- démarre les 2 touches ⌘R (cmd R) tenues pressées jusqu'à l'affichage d'une = démarrage sur l'OS de secours. Tu obtiens un écran affichant une fenêtre de 4 Utilitaires macOS. Va à la barre de menus supérieure de l'écran > menu : Utilitaires > sous-menu : Terminal.
Dans la fenêtre ouverte > saisis la commande informative :
Bloc de code:
diskutil list- tu vas voir s'afficher le tableau des disques attachés au Mac (en interne / externe) > avec leurs paramètres de tables de partition > partitions > Conteneur CoreStorage si présent > Conteneur apfs si présent
- une série de micro-disques correspond à des images-disques créées en RAM à l'occasion du démarrage en mode Recovery > dont les volumes sont montés en lecture & écriture à l'espace de dossiers de l'OS de secours qui leur servent de points de montage. Ce qui permet pendant le fonctionnement de cet OS monté en lecture seule > à des écritures de s'effectuer à l'espace des dossiers où se trouvent montés les volumes des images-disques de la RAM. Ces images-disques s'effacent à l'extinction ou au re-démarrage.
Voici comment tu vas pouvoir poster ici ce tableau sans avoir besoin de prendre de photo -->
- tu sélectionnes le tableau > ⌘C pour le copier dans le presse-papier > ⌘Q pour quitter le «Terminal» > option : "Obtenir de l'aide en ligne" (dans la fenêtre des 4 Utilitaires) > ce qui lance un navigateur «Safari»
- page Apple par défaut > un clic sur l'adresse de haut de page pour l'éditer > saisis : macgénération (tout court : c'est une barre de recherche Google) et valide > tu atteins le site MacGé > Forums > te connectes > ce fil
- dans cette page de MacGé > presse le bouton
ici :
menu : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)
=> ces informations montreront la configuration logique de ton disque.
Note 1 : si tu ne peux pas poster via le Safari de la session de secours (ça arrive) --> poste une photo du tableau (à partir du commencement = le disque /dev/disk0 ou disque physique interne) - tu as un bouton : "Transférer un fichier" en bas de cette page.
Note 2 : dans la session de secours > les applications se lancent en mode "alternatif" et pas parallèle. Il faut quitter le Terminal pour lancer Safari. Vice-versa > quitter Safari pour récupérer l'écran général de la session de secours et pouvoir relancer le Terminal. Aucun redémarrage n'est requis.
Désolé je n’ai pas pu me connecter à mon utilisateur de lordi car j’ai oublié mon mdp...:/ J’ai donc posté une photo.
M
Membre supprimé 1060554
Invité
La partition de l'OS présente un type : "Apple_HFS" classique > mais aucun volume ne se trouve affiché sur cette partition -->
- est-ce que tu avais des données à récupérer ?
