Impossible de supprimer partition Bootcamp
- Créateur du sujet Genox
- Date de début
M
Membre supprimé 1060554
Invité
Pourtant le disque interne est bien disk0 comme je l'avais supposé d'entrée.
Il est impossible qu'un volume soit monté sur la partition disk0s2 de l'OS et je ne vois pas comment les 2 autres partitions auraient des volumes montés, car leur type de partition (EFI et Apple_Boot) le proscrit.
Passe la commande :
=> est-ce que tu obtiens quelque chose comme :
ou pas ?
Il est impossible qu'un volume soit monté sur la partition disk0s2 de l'OS et je ne vois pas comment les 2 autres partitions auraient des volumes montés, car leur type de partition (EFI et Apple_Boot) le proscrit.
Passe la commande :
Bloc de code:
diskutil umountDisk force disk0- qui démonte de force tous les volumes supportés par le disque n°0
=> est-ce que tu obtiens quelque chose comme :
Bloc de code:
Forced unmount of all volumes on disk0 was successful
M
Membre supprimé 1060554
Invité
Pfuiiii ! Hé ben... faut s'accrocher parfois... Bonne nouvelle.
Enchaîne avec la commande :
Si tu n'as pas de message d'erreur > passe un :
et poste une photo > que je vérifie la distribution des partitions.
Enchaîne avec la commande :
Bloc de code:
diskutil eraseVolume jhfs+ SOS disk0s4- qui injecte un système de fichiers JHFS+ dans le conteneur de la partition disk0s4 et remonte un volume intitulé SOS.
Si tu n'as pas de message d'erreur > passe un :
Bloc de code:
diskutil listet poste une photo > que je vérifie la distribution des partitions.
M
Membre supprimé 1060554
Invité
Tu as désormais un volume SOS de 49,6 Go à ta disposition.
Si tu activais l'option : "Ré-installer OS X" de la fenêtre des 4 Utilitaires OS X de l'Internet Recovery > c'est l'OS-d'usine du Mac qui te serait proposé à réinstaller. Ce qui n'est pas intéressant.
Alors re-démarre (pour quitter l'OS de l'Internet Recovery en RAM - ce qui va l'effacer) > et tiens pressées les 2 touches ⌘R à partir de l'écran noir. Tu vas donc revenir sur l'OS de secours de la Recovery locale (du disque) > et l'option "Ré-installer OS X" te proposera bien «El Capitan».
Active donc cette option : "Ré-installer OS X" à destination du volume SOS > et tu pourras dans un moment ouvrir une session dans l'OS «El Capitan» de ce volume. Tu n'auras qu'à le signaler alors.
Si tu activais l'option : "Ré-installer OS X" de la fenêtre des 4 Utilitaires OS X de l'Internet Recovery > c'est l'OS-d'usine du Mac qui te serait proposé à réinstaller. Ce qui n'est pas intéressant.
Alors re-démarre (pour quitter l'OS de l'Internet Recovery en RAM - ce qui va l'effacer) > et tiens pressées les 2 touches ⌘R à partir de l'écran noir. Tu vas donc revenir sur l'OS de secours de la Recovery locale (du disque) > et l'option "Ré-installer OS X" te proposera bien «El Capitan».
Active donc cette option : "Ré-installer OS X" à destination du volume SOS > et tu pourras dans un moment ouvrir une session dans l'OS «El Capitan» de ce volume. Tu n'auras qu'à le signaler alors.
M
Membre supprimé 1060554
Invité
¡ Hola !
Je suppose que tu as pu ouvrir une session dans l'OS «El Capitan» installé dans le volume SOS.
Alors voici l'étape suivante : tu télécharges l'utilitaire ☞gdisk☜ (clique le lien rouge) de Roderick Smith (le développeur de «rEFInd») > ce qui te fait acquérir un paquet d'installation intitulé : gdisk-1.0.3.pkg. Tu le double-cliques et un exécutable gdisk va se trouver installé à l'adresse : /usr/local/bin/gdisk (/usr est un des répertoires invisibles graphiquement dans l'OS où se trouvent localisés des utilitaires exécutables). Tu peux désormais appeler directement gdisk dans le «Terminal».
----------
Tu lances le «Terminal» de l'OS (que tu trouves à l'adresse : Applications > Utilitaires > «Terminal.app»). Dans sa fenêtre > tu appelles gdisk à destination de la table de partition de ton disque interne qui est nécessairement disk0 par la commande :
--> après validation > une demande de password s'affiche (commande sudo pour passer en droits root - car tu n'es plus -bash-3.2#, càd. un avatar de root ici > tu es kasual$ : un simple admin, qui doit élever ses privilèges en s'authentifiant pour pouvoir adresser la table de partition GPT du disque) --> tape ton mot-de-passe de session admin à l'aveugle - aucun caractère ne se montrant à la frappe - et valide de nouveau.
Tu devrais obtenir l'affichage suivant :
la dernière ligne Command (? for help): étant l'invite de commande du menu "Main" (principal) de gdisk. Il s'agit d'une interface interactive avec gdisk > où tu vas pouvoir saisir des commandes adressées à ce programme et consistant en la saisie de simples lettres suivie d'une validation avec la touche "Entrée" (↩︎) --> ce qui suscite chaque fois un retour d'affichage de gdisk.
Saisis la commande :
(changer le type d'une partition) et ↩︎ --> tu obtiens le retour :
te demandant de choisir un numéro de rang de partition comme cible.
Saisis la commande :
(choix de la partition n°2 du disque - celle qui est corrompue) et ↩︎ --> tu obtiens le retour :
- où je ne ne peux pas anticiper ce que le programme gdisk va détecter comme type (ou non type) logique actuel de ta partition --> quoi qu'il en soit > tu es invité à saisir un code désignant le nouveau type que tu veux voir inscrit dans la table GPT pour cette partition n°2.
Saisis la commande :
(Apple_Filesystem_00 --> il s'agit de deux zéros) et ↩︎ --> tu obtiens le retour :
--> malgré la déclaration : "type de partition changé à "Apple_HFS/HFS+" > il faut bien comprendre que ce changement n'a été effectué que dans un cache du programme gdisk > et que la table GPT n'a pour l'instant pas le moins du monde été sur-écrite. Le Command (? for help): est le ré-affichage de l'invite de commande principale.
Saisis la commande :
(write : écrire le cache à la table de partition GPT) et ↩︎ --> tu obtiens le retour :
--> l'alerte préliminaire dit que : la vérification finale a été accomplie. Le programme gdisk est sur le point d'écrire à la table de partition GPT. Cet acte d'écriture va éditer l'inscription dans la table de partitions existantes. Cette alerte est classique : elle est l'annonce de la totale supériorité logique du programme gdisk sur le programme standard gpt > en ce que gdisk est capable d'ouvrir la table de partition GPT d'un disque en mode "live" > alors que des volumes se trouvent actuellement montés, voire démarrés, sur des partitions de ce disque. Bien qu'on se trouve dans le cas d'une « Resource busy » (ressource occupée) > cet état de choses ne bloque pas gdisk qui va pouvoir doubler le kernel (le noyau du Système «El Capitan» démarré) qui charge actuellement les partitions de la table GPT du disque > pour écrire au fichier original de l'en-tête du disque.
Donc en réponse à la demande interactive : Do you want to proceed? (Y/N): (voulez-vous exécutez l'action ?) -->
Saisis la commande :
(yes) et ↩︎ --> tu obtiens le retour :
Cette annonce classique de gdisk déclare exécutée l'édition de la table de partition GPT active du disk0. Les avertissements qui suivent reflètent la puissance opératoire de gdisk : le programme a été capable de modifier les écritures originales de la table de partition GPT de l'en-tête du disque > sans que le kernel s'en soit aperçu le moins du monde > car le kernel charge les partitions d'une table de partition dans l'équivalent d'une « mémoire-cache », ce qui fait qu'il est possible à un programme puissant de modifier les inscriptions des partitions dans la table originale sans que le chargement des partitions dans le cache de kernel soit le moins du monde affecté.
L'invite de commande normale du «Terminal» (du style : kasual$) est restituée, montrant que le programme gdisk a coupé. Il arrive, lorsque l'action d'écriture de gdisk est une rectification du type d'une partition (changement du code) > et que ce changement de type restaure la conformité avec le système de fichiers existant dans le conteneur de la partition > que le volume remonte instantanément (comme un ballon gonflé à l'hélium) sur la partition.
----------
Si le seul changement logique qui ait affecté la partition disk0s2 a été une corruption de son type de partition > sans que le système de fichiers JHFS+ ait été du tout affecté (pas de reformatage) --> alors la restauration du code AF00 correct peut redonner immédiatement accès au système de fichiers pour le service diskarbitrationd de l'OS «El Capitan». Si ce service (qui est un serveur permanent de l'OS) détecte un système de fichiers JHFS+ qui passe la probation sans erreur > il y a une chance qu'il passe instantanément la tâche au kernel de remonter le volume correspondant sur la partition.
Si tu ne vois pas affiché sur ton Bureau de session le volume Mactinosh HD remonté sur la partition disk0s2 > re-démarre une fois > en rebootant sur le volume SOS et vérifie si le Finder t'affiche le volume Macintosh HD. Si ce n'est pas le cas (ou même si ça l'est) > repasse une commande :
et poste le tableau des partitions retourné.
Tu seras du moins absolument sûr d'une chose : le code associé à la partition disk0s2 est désormais le bon > donc son type est fixé adéquatement dans la table de partition GPT comme "porte d'accès" à la lecture du système de fichiers par le service diskarbitrationd. Si le volume Macintosh HD n'a pas été remonté dans la foulée > c'est qu'à partir de ton OS «Ubuntu» tu aurais affecté le système de fichiers JHFS+ de la partition disk0s2 et pas seulement le type de la partition en changeant son code.
Je suppose que tu as pu ouvrir une session dans l'OS «El Capitan» installé dans le volume SOS.
Alors voici l'étape suivante : tu télécharges l'utilitaire ☞gdisk☜ (clique le lien rouge) de Roderick Smith (le développeur de «rEFInd») > ce qui te fait acquérir un paquet d'installation intitulé : gdisk-1.0.3.pkg. Tu le double-cliques et un exécutable gdisk va se trouver installé à l'adresse : /usr/local/bin/gdisk (/usr est un des répertoires invisibles graphiquement dans l'OS où se trouvent localisés des utilitaires exécutables). Tu peux désormais appeler directement gdisk dans le «Terminal».
----------
Tu lances le «Terminal» de l'OS (que tu trouves à l'adresse : Applications > Utilitaires > «Terminal.app»). Dans sa fenêtre > tu appelles gdisk à destination de la table de partition de ton disque interne qui est nécessairement disk0 par la commande :
Bloc de code:
sudo gdisk /dev/disk0Tu devrais obtenir l'affichage suivant :
Bloc de code:
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help):Saisis la commande :
Bloc de code:
t
Bloc de code:
Partition number (1-5):Saisis la commande :
Bloc de code:
2
Bloc de code:
Current type is 'xxxxxxxxxxxxx'
Hex code or GUID (L to show codes, Enter = AF00):Saisis la commande :
Bloc de code:
AF00
Bloc de code:
Changed type of partition to 'Apple HFS/HFS+'
Command (? for help):Saisis la commande :
Bloc de code:
w
Bloc de code:
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N):Donc en réponse à la demande interactive : Do you want to proceed? (Y/N): (voulez-vous exécutez l'action ?) -->
Saisis la commande :
Bloc de code:
y
Bloc de code:
OK; writing new GUID partition table (GPT) to /dev/disk0.
Warning: Devices opened with shared lock will not have their partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.Cette annonce classique de gdisk déclare exécutée l'édition de la table de partition GPT active du disk0. Les avertissements qui suivent reflètent la puissance opératoire de gdisk : le programme a été capable de modifier les écritures originales de la table de partition GPT de l'en-tête du disque > sans que le kernel s'en soit aperçu le moins du monde > car le kernel charge les partitions d'une table de partition dans l'équivalent d'une « mémoire-cache », ce qui fait qu'il est possible à un programme puissant de modifier les inscriptions des partitions dans la table originale sans que le chargement des partitions dans le cache de kernel soit le moins du monde affecté.
L'invite de commande normale du «Terminal» (du style : kasual$) est restituée, montrant que le programme gdisk a coupé. Il arrive, lorsque l'action d'écriture de gdisk est une rectification du type d'une partition (changement du code) > et que ce changement de type restaure la conformité avec le système de fichiers existant dans le conteneur de la partition > que le volume remonte instantanément (comme un ballon gonflé à l'hélium) sur la partition.
----------
Si le seul changement logique qui ait affecté la partition disk0s2 a été une corruption de son type de partition > sans que le système de fichiers JHFS+ ait été du tout affecté (pas de reformatage) --> alors la restauration du code AF00 correct peut redonner immédiatement accès au système de fichiers pour le service diskarbitrationd de l'OS «El Capitan». Si ce service (qui est un serveur permanent de l'OS) détecte un système de fichiers JHFS+ qui passe la probation sans erreur > il y a une chance qu'il passe instantanément la tâche au kernel de remonter le volume correspondant sur la partition.
Si tu ne vois pas affiché sur ton Bureau de session le volume Mactinosh HD remonté sur la partition disk0s2 > re-démarre une fois > en rebootant sur le volume SOS et vérifie si le Finder t'affiche le volume Macintosh HD. Si ce n'est pas le cas (ou même si ça l'est) > repasse une commande :
Bloc de code:
diskutil listTu seras du moins absolument sûr d'une chose : le code associé à la partition disk0s2 est désormais le bon > donc son type est fixé adéquatement dans la table de partition GPT comme "porte d'accès" à la lecture du système de fichiers par le service diskarbitrationd. Si le volume Macintosh HD n'a pas été remonté dans la foulée > c'est qu'à partir de ton OS «Ubuntu» tu aurais affecté le système de fichiers JHFS+ de la partition disk0s2 et pas seulement le type de la partition en changeant son code.
Dernière édition par un modérateur:
Enfin un message depuis mon Macbook !
Et enfin récupérer un 'diskutil list' qui ressemble à quelque chose !
Et enfin récupérer un 'diskutil list' qui ressemble à quelque chose !
Bloc de code:
MacBook-Pro-de-Alex:~ alex$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS 200.5 GB disk0s2
3: Apple_HFS Recovery HD 650.0 MB disk0s3
4: Apple_CoreStorage SOS 49.0 GB disk0s4
5: Apple_Boot Recovery HD 650.0 MB disk0s5
/dev/disk1 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS SOS +48.6 GB disk1
Logical Volume on disk0s4
9900089F-F2CC-4A7A-A3EE-272AA6F609A8
Unencrypted
M
Membre supprimé 1060554
Invité
La partition disk0s2 a bien récupéré son TYPE conforme = Apple_HFS. Mais je constate qu'aucun nom de volume ne lui est associé à la rubrique NAME.
=> est-ce que tu as re-démarré après ton opération avec gdisk ?
=> est-ce que tu as re-démarré après ton opération avec gdisk ?
M
Membre supprimé 1060554
Invité
Est-ce que tu te souviens de l'opération que tu avais effectuée sur cette partition ? - tu étais dans «Ubuntu» ?
Il me semble que je n'ai fait aucune commande concernant disk0s2 avant de poster ici.
J'ai seulement réparer le disque dans Utilitaire de Disque en mode Recovery après avoir suivi les commandes que tu as indiqués au tout début de ce topic. J'avais déjà supprimé Ubuntu avant d'avoir ce problème.
J'ai seulement réparer le disque dans Utilitaire de Disque en mode Recovery après avoir suivi les commandes que tu as indiqués au tout début de ce topic. J'avais déjà supprimé Ubuntu avant d'avoir ce problème.
M
Membre supprimé 1060554
Invité
Je viens de relire ton 1er message.
Effectivement les 2 commandes par lesquelles tu avais supprimé les 2 partitions Linux (disk0s4 & disk0s5) étaient valides et inoffensives pour la partition disk0s2 de l'OS.
Je suppose que tu as passé ensuite une commande du type :
Est-ce que tu te souviens de ce qui a bloqué alors - genre : quel message d'erreur affiché dans la fenêtre du «Terminal» ?
Effectivement les 2 commandes par lesquelles tu avais supprimé les 2 partitions Linux (disk0s4 & disk0s5) étaient valides et inoffensives pour la partition disk0s2 de l'OS.
Je suppose que tu as passé ensuite une commande du type :
Bloc de code:
diskutil resizeVolume disk0s2 0b- pour récupérer l'espace libre à la partition de l'OS > mais que ça n'a pas marché.
Est-ce que tu te souviens de ce qui a bloqué alors - genre : quel message d'erreur affiché dans la fenêtre du «Terminal» ?
Peut-être des indices :
Je ne boot plus comme avant : plus d'attente de 5 secondes sur fond noir avec son d'ouverture, plus reFind en ouverture qui me propose un boot sur Linux (qui ne menait à rien), un boot OS X qui menait sur un bouton stop blanc sur fond noir que j'ai envoyé et le mode Recovery. Je boot directement sur la session SOS.
Je ne boot plus comme avant : plus d'attente de 5 secondes sur fond noir avec son d'ouverture, plus reFind en ouverture qui me propose un boot sur Linux (qui ne menait à rien), un boot OS X qui menait sur un bouton stop blanc sur fond noir que j'ai envoyé et le mode Recovery. Je boot directement sur la session SOS.
Fichiers joints
M
Membre supprimé 1060554
Invité
Est-ce que tu te souviens si une vérification du système de fichiers s'était lancée et affichée > l'échec du re-dimensionnement intervenant à cause d'une erreur détectée > un message t'invitant à réparer le disque en re-démarrant sur le système de secours (= Recovery) ?
Ou bien si l'échec était intervenu immédiatement > un message indiquant que cette commande n'était pas supportée par le format de la partition ? - ce qui aurait alors signifié qu'un système de stockage CoreStorage était incrit sur la partition disk0s2. - est-ce que tu te souviens, si tu avais fait au départ un diskutil list, s'il y avait mention d'un type Apple_Coretorage de cette partition > ou s'il y avait affichage en bas de tableau d'un disque supplémentaire (internal, virtual) disk1 intitulé Logical Volume avec un UUID de type : XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ?
Ou bien si l'échec était intervenu immédiatement > un message indiquant que cette commande n'était pas supportée par le format de la partition ? - ce qui aurait alors signifié qu'un système de stockage CoreStorage était incrit sur la partition disk0s2. - est-ce que tu te souviens, si tu avais fait au départ un diskutil list, s'il y avait mention d'un type Apple_Coretorage de cette partition > ou s'il y avait affichage en bas de tableau d'un disque supplémentaire (internal, virtual) disk1 intitulé Logical Volume avec un UUID de type : XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ?
Après avoir effectué les commandes suivantes :
J'ai ensuite effectué ces commandes qui ont échoués :
Et enfin celle ci qui a également échouée :
Un message très court (1-2 ligne) m'a indiqué que l'espace disque n'a pas pu être récupéré.
Aucun message ne m'a invité a redémarrer en Recovery, c'est le message d'Alcor72, message #8 de ce topic qui m'a incité à le faire.
L'échec est donc intervenu immédiatement. Il est très probable que j'ai reçu ce message indiquant que cette commande n'était pas supportée par le format de la partition. Je ne sais pas s'il y avait un type Apple_Corestorage de cette partition.
Je n'ai eu de format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX dans un disque virtuel et physique. Seul mon disk0s2 a pris cette forme comme on le voit au message #61 en haut de cette page.
Bloc de code:
sudo diskutil eraseVolume free NULL /dev/disk0s4
sudo diskutil eraseVolume free NULL /dev/disk0s5
Bloc de code:
sudo diskutil umount force /dev/disk0s4
sudo diskutil umount force /dev/disk0s5
Bloc de code:
sudo diskutil resizeVolume /dev/disk0s2 0bAucun message ne m'a invité a redémarrer en Recovery, c'est le message d'Alcor72, message #8 de ce topic qui m'a incité à le faire.
L'échec est donc intervenu immédiatement. Il est très probable que j'ai reçu ce message indiquant que cette commande n'était pas supportée par le format de la partition. Je ne sais pas s'il y avait un type Apple_Corestorage de cette partition.
Je n'ai eu de format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX dans un disque virtuel et physique. Seul mon disk0s2 a pris cette forme comme on le voit au message #61 en haut de cette page.
M
Membre supprimé 1060554
Invité
Comme tu es connecté, kasui, voici 2 commandes à passer qui devraient permettre de savoir si la partition disk0s2 accueillait un système de fichiers JHFS+ ou un système de stockage CoreStorage.
Par la commande :
Par la commande :
Tu n'as qu'à poster le tableau ici dans une fenêtre de Code.
=> s'il y a eu un système de stockage CoreStorage sur la partition disk0s2 > alors il devrait y avoir 2 dossiers spéciaux dans le volume Recovery HD : le com.apple.recovery.boot du système de secours et un dossier com.apple.Boot.R contenant le « booter » ou pré-démarreur du Volume Logique du CoreStorage.
Par la commande :
Bloc de code:
diskutil mount disk0s3- tu montes le volume Recovery HD sur la partition disk0s3 auxiliaire de la disk0s2
Par la commande :
Bloc de code:
ls -R /Volumes/"Recovery HD"- tu listes récursivement le contenu du volume Recovery HD monté
Tu n'as qu'à poster le tableau ici dans une fenêtre de Code.
=> s'il y a eu un système de stockage CoreStorage sur la partition disk0s2 > alors il devrait y avoir 2 dossiers spéciaux dans le volume Recovery HD : le com.apple.recovery.boot du système de secours et un dossier com.apple.Boot.R contenant le « booter » ou pré-démarreur du Volume Logique du CoreStorage.
Dernière édition par un modérateur:
Voici le résultat.
Bloc de code:
MacBook-Pro-de-Alex:~ alex$ ls -R /Volumes/"Recovery HD"
AdminInfo.plist com.apple.boot.R
System com.apple.recovery.boot
/Volumes/Recovery HD/System:
Library
/Volumes/Recovery HD/System/Library:
CoreServices
/Volumes/Recovery HD/System/Library/CoreServices:
PlatformSupport.plist SystemVersion.plist boot.efi
/Volumes/Recovery HD/com.apple.boot.R:
Library System usr
/Volumes/Recovery HD/com.apple.boot.R/Library:
Preferences
/Volumes/Recovery HD/com.apple.boot.R/Library/Preferences:
SystemConfiguration
/Volumes/Recovery HD/com.apple.boot.R/Library/Preferences/SystemConfiguration:
com.apple.Boot.plist
/Volumes/Recovery HD/com.apple.boot.R/System:
Library
/Volumes/Recovery HD/com.apple.boot.R/System/Library:
Caches PrelinkedKernels
/Volumes/Recovery HD/com.apple.boot.R/System/Library/Caches:
com.apple.corestorage
/Volumes/Recovery HD/com.apple.boot.R/System/Library/Caches/com.apple.corestorage:
EFILoginLocalizations EncryptedRoot.plist.wipekey
/Volumes/Recovery HD/com.apple.boot.R/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations:
Lucida13.efires disk_passwordUI.efires preferences.efires
Lucida13White.efires flag_picker.efires unknown_userUI.efires
appleLogo.efires guest_userUI.efires
battery.efires loginui.efires
/Volumes/Recovery HD/com.apple.boot.R/System/Library/PrelinkedKernels:
prelinkedkernel
/Volumes/Recovery HD/com.apple.boot.R/usr:
standalone
/Volumes/Recovery HD/com.apple.boot.R/usr/standalone:
i386
/Volumes/Recovery HD/com.apple.boot.R/usr/standalone/i386:
EfiLoginUI
/Volumes/Recovery HD/com.apple.boot.R/usr/standalone/i386/EfiLoginUI:
Lucida13.efires disk_passwordUI.efires recoveryUI.efires
Lucida13White.efires flag_picker.efires recovery_user.efires
appleLogo.efires guest_userUI.efires sound.efires
battery.efires loginui.efires unknown_userUI.efires
/Volumes/Recovery HD/com.apple.recovery.boot:
BaseSystem.chunklist SystemVersion.plist prelinkedkernel
BaseSystem.dmg boot.efi
PlatformSupport.plist com.apple.Boot.plistSujets similaires
