10.11 El Capitan Volume de démarrage accessible uniquement via une autre partition

Yohmi

Yohmi

Membre confirmé
4 Octobre 2007
43
20
www.wan-way.net
Salut à tous !

J'ai un MacBook Pro retina, sur lequel j'ai une grande partition dédiée à El Capitan, et une toute petite pour tester Sierra. En voulant mettre à jour Sierra ce matin, le système me dit que je n'ai pas assez d'espace disponible (j'ai pourtant 7 Go de libre… m'enfin bon). Alors je décide de redimensionner la partition à la volée. Sur Sierra, on ne me le permet pas. Tout ce que j'arrive à faire, c'est à créer une troisième partition. Je décide alors de la supprimer, et l'espace retourne donc, logiquement, à ma partition El Capitan.

Mais voilà. Je me dis que je verrai ça plus tard car Sierra c'est pas le plus important. Je redémarre, avec la touche « alt » enfoncée, et là, stupeur, il n'y a plus que le volume de Sierra qui s'affiche.
Je retourne donc sur Sierra, ouf, le volume est toujours là. Tout beau, je peux naviguer dans l'arborescence, transférer des fichiers… bref, tout va bien. Alors je me dis que c'est juste un coup de sang de mon Mac, je re-tente, même topo. Bon, c'est pas drôle. Je vais voir dans les Préférences Système, puis dans Disque de Démarrage. Je vois bien mon volume, mais quand je veux le mettre par défaut, ce message s'affiche :

Vous ne pouvez pas modifier le disque de démarrage du disque sélectionné.
La génération de caches de démarrage sur la partition de l’utilitaire de démarrage a échoué.​

Les recherches à partir de ce message d'erreur (ainsi que de sa version originale "Building boot caches on boot helper partition failed") m'ont mené à des résultats (désactiver SIP, utiliser la commande "bless"…) qui s'appliquent à des personnes chez qui le volume apparaît au démarrage, contrairement à moi, et j'ai peur qu'en forçant le système de la sorte, ça ne démarre tout simplement plus du tout. Il y a bien un sujet sur ce forum, mais la victime dit que c'est parti comme c'est venu… j'espère, mais je n'y crois pas trop.

J'ai effectué un SOS Disque sur tous les volumes, sur le disque général j'obtiens :
Problèmes rencontrés sur la carte de partition risquant d'empêcher le démarrage​
Tandis que sur mon volume El Capitan :
Impossible de démonter le volume pour le réparer. L'opération a échoué…​

J'ai tenté la même opération via la partition de récupération (cmd+r) ainsi qu'en mode "sans extensions" (maj), toujours le même résultat. J'ai également effectué une remise à zéro de la NVRam, sans succès. Je rechigne à utiliser Onyx puisque je suis sur la bêta publique de Sierra, donc c'est plutôt dangereux.

Alors je ne sais pas trop quoi faire. Peut-être faudrait-il lancer un SOS Disque sur une partition de récupération externe ? (je ne sais pas comment faire mais ça doit se trouver…)
J'ai encore accès à toutes mes données, je me suis donc empressé de sauvegarder ma musique et mes photos comme je le fais régulièrement. J'ai la place pour sauvegarder tout mon répertoire utilisateur (la petite maison) sur un disque externe (ça va prendre du temps, mais c'est faisable).

Quelqu'un connaît-il un moyen pour résoudre ce souci de partition ? C'est trop bête, tout est là, ça veut juste pas démarrer…

Sinon, est-il envisageable de sauvegarder mon répertoire Utilisateur, d'effacer la partition d'El Capitan, de réinstaller El Capitan et de restaurer ce répertoire via un simple et interminable copier/coller ? J'ai bien une sauvegarde Time Machine, mais elle doit avoir deux semaines, ça serait dommage de perdre ces deux semaines (même s'il n'y a rien de très important, hormis des photos, et celles-là je les ai sauvegardées manuellement).

Merci d'avance :)
 
Salut Yohmi

Je m'interroge autant que toi sur le facteur exact qui a fait que ton volume El Capitan ne soit plus reconnu comme "démarrable" au démarrage avec "alt" - option qui déclenche un programme auxiliaire de l'EFI (Programme Interne recelé dans une puce de la Carte-Mère) : le BootManager (gestionnaire de démarrage), lequel scanne les volumes montés disponibles afin de n'afficher que les volumes arborant la propriété "démarrable".

Apparemment, le volume «El Capitan» a perdu cette propriété, et n'est plus reconnu que comme « disque de stockage » (à l'instar de celui d'un simple DDE) > par conséquent, il se trouve exclu d'affichage à l'écran de choix du disque de démarrage déployé par le BootManager.

--------------------​

Ce que tu peux faire, à partir de ta session ouverte dans «Sierra» > aller à : Applications > Utilitaires > lancer le «Terminal» > passer 2 commandes (purement informatives => n'agissent qu'en « lecture seule ») :

- a) d'abord :
Bloc de code: 
diskutil list
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> en retour, tu vas obtenir l'affichage des disques attachés à ton Mac, avec leurs partitions décrites selon des paramètres de format > nom > taille > device.

- b) ensuite :
Bloc de code: 
diskutil cs list
et ↩︎ --> comme tu as vraisemblablement des formats CoreStorage sur la partition d'«El Capitan» et sur celle de «Sierra» (greffés par les installateurs de ces OS) --> tu vas voir s'afficher le(s) tableau(x) en arborescence d'un (ou de deux) Groupe(s) de Volumes Logiques.​

=> peux-tu faire un copier-coller ici des tableaux complets retournés par les 2 commandes ? C'est pour avoir déjà une idée du dispositif logique général de ton disque.
 
Dernière édition par un modérateur:
Tout d'abord, merci beaucoup pour ta réponse :)

Alors, voici ce que la première commande retourne :

Bloc de code: 
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage HAL 9000                973.5 GB   disk0s2
   3:                 Apple_Boot                         650.0 MB   disk0s3
   4:                  Apple_HFS Sans titre              6.8 GB     disk0s4
   5:          Apple_CoreStorage SierraBeta              18.7 GB    disk0s5
   6:                 Apple_Boot Recovery HD             650.0 MB   disk0s6

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            HAL 9000               +973.1 GB   disk1
                                 Logical Volume on disk0s2
                                 2A7E47FA-AF67-4890-8FB8-70C6183783D2
                                 Unencrypted

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            SierraBeta             +18.3 GB    disk2
                                 Logical Volume on disk0s5
                                 FCB96808-6161-45ED-BAC1-78C18CAC9683
                                 Unencrypted

Et pour la seconde :

Bloc de code: 
CoreStorage logical volume groups (2 found)
|
+-- Logical Volume Group F48774C8-22D5-4D84-8E41-B0E1C6F0D14A
|   =========================================================
|   Name:         SierraBeta
|   Status:       Online
|   Size:         18699997184 B (18.7 GB)
|   Free Space:   10178560 B (10.2 MB)
|   |
|   +-< Physical Volume AF281840-6FBF-42ED-A605-75FAF540B7E1
|   |   ----------------------------------------------------
|   |   Index:    0
|   |   Disk:     disk0s5
|   |   Status:   Online
|   |   Size:     18699997184 B (18.7 GB)
|   |
|   +-> Logical Volume Family 10BD5337-6312-49F7-8474-ED4C831CA649
|       ----------------------------------------------------------
|       Encryption Type:         None
|       |
|       +-> Logical Volume FCB96808-6161-45ED-BAC1-78C18CAC9683
|           ---------------------------------------------------
|           Disk:                  disk2
|           Status:                Online
|           Size (Total):          18337497088 B (18.3 GB)
|           Revertible:            Yes (no decryption required)
|           LV Name:               SierraBeta
|           Volume Name:           SierraBeta
|           Content Hint:          Apple_HFS
|
+-- Logical Volume Group 2BC69876-CC09-4517-81C3-55963384EFDF
    =========================================================
    Name:         HAL 9000
    Status:       Online
    Size:         973457276928 B (973.5 GB)
    Free Space:   0 B (0 B)
    |
    +-< Physical Volume E780D150-DD60-43AF-9FF4-1DD0DE9C1873
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     973457276928 B (973.5 GB)
    |
    +-> Logical Volume Family 2CF1594D-CE21-4993-9CFF-7F3FB76F100E
        ----------------------------------------------------------
        Encryption Type:         None
        |
        +-> Logical Volume 2A7E47FA-AF67-4890-8FB8-70C6183783D2
            ---------------------------------------------------
            Disk:                  disk1
            Status:                Online
            Size (Total):          973104955392 B (973.1 GB)
            Revertible:            Yes (no decryption required)
            LV Name:               HAL 9000
            Volume Name:           HAL 9000
            Content Hint:          Apple_HFS

Je ne sais pas vraiment quoi regarder dans ces résultats, mais rien ne saute aux yeux à première vue… à part les données « Free Space » qui donnent des résultats étranges, mais peut-être que je les interprète mal.
À noter que le volume « Sans Titre » est une partition que j'ai créée ensuite pour essayer de conjurer le sort, en me disant que ça pouvait peut-être lui donner envie de faire du ménage dans les partitions… visiblement, non.
 
Tu as effectivement 2 CoreStorages (un sur la partition disk0s2 d'«El Capitan» = HAL 9000 ; un sur la partition disk0s5 de «Sierra» = SierraBeta). Rien ne manque dans le dispositif logique de chacun.

--------------------​

Ta petite partition disk0s4 Sans titre de 6,8 Go ne sert à rien (si même elle ne gêne pas). Je te propose 2 commandes pour récupérer son espace libre à la partition disk0s2 d'«El Capitan» (HAL 9000) :

- a) d'abord :
Bloc de code: 
diskutil eraseVolume free NULL /dev/disk0s4
qui va supprimer le système de fichiers de cette petite partition et ainsi virer son espace de blocs au statut de free_space hors table de partition (c'est la condition préalable pour pouvoir récupérer cet espace à la partition HAL 9000).

- b) ensuite :
Bloc de code: 
diskutil coreStorage resizeStack 2A7E47FA-AF67-4890-8FB8-70C6183783D2 0b
--> cette commande appelle l'utilitaire diskutil (disk_utility) > avec la spécification CoreStorage (cs en abrégé) > le verbe resizeStack (redimensionner la pile de volumes logiques du CoreStorage) > l'UUID du Logical Volume disk1 exporté par le CoreStorage de la partition HAL 9000 comme cible > la mention 0b qui revient à dire en abrégé : "récupérer le free_space disponible en-dessous du volume-cible jusqu'à épuisement du dernier byte, ce sans obstacle d'une partition «Recovery HD» dont l'emplacement sera mis à jour sur les blocs".

Tu dois savoir qu'en préalable d'un re-dimensionnement > une vérification d'intégrité du système de fichiers bénéficiaire est lancée (ici il s'agit du système de fichiers jhfs+ ancré sur le Volume Logique terminal HAL 9000 du CoreStorage) > en cas d'erreur trouvée, l'utilitaire fsck_hfs va tenter de les réparer (en démontant le système de fichiers concerné, ce qui sera possible en principe, puisque tu n'es pas démarré dessus, mais sur le Système alternatif «Sierra»).

=> Je suis curieux de savoir : si des erreurs sont trouvées ; si elles peuvent être réparées ; si le re-dimensionnement final s'exécute.

--------------------​

Je note par ailleurs un état bizarre de la partition de récupération «Recovery HD» collatérale en disk0s3 de ta partition HAL 9000 en disk0s2 => si le format spécifique de cette partition est annoncé = Apple_Boot ; par contre aucun nom de volume (qui devrait être : Recovery HD) n'est mentionné, comme s'il n'y avait pas un tel intitulé dans le système de fichiers concerné.

Pour satisfaire ma curiosité, si tu passes dans ton «Terminal» (de «Sierra» toujours) la commande:
Bloc de code: 
diskutil mount /dev/disk0s3
=> est-ce que tu vois s'afficher sur ton Bureau de session l'icône d'un volume monté Recovery HD ou non ?

--------------------
​
=> ces diverses manipulations ne s'attaquent pas directement à ton problème, mais vont permettre de savoir s'il y a des blocages du CoreStorage ou de la Recovery HD.​
 
Les deux opérations ont été effectuées sans encombre, et mon volume El Capitan a bien récupéré ce qu'il manquait. Par contre, la commande subsidiaire retourne une erreur :
Bloc de code: 
Volume on disk0s3 failed to mount
If the volume is damaged, try the "readOnly" option
J'ai essayé la commande :
Bloc de code: 
diskutil mount readOnly /dev/disk0s3
Volume on disk0s3 failed to mount
If the volume is damaged, try the "readOnly" option
Invariable réponse… j'ai bien vérifié dans la liste après avoir supprimé et réattribué l'espace à mon volume El Capitan, Apple_Boot est toujours disk0s3, mais semble bel et bien inaccessible. Aucun volume supplémentaire n'apparaît.

Au cas où, je suis allé voir, et rien n'a changé, il n'y a toujours que le volume Sierra qui s'affiche au démarrage :(
 
C'est bien ce que subodorais : le système de fichiers de la partition de récupération «Recovery HD» est inmontable, ou même a été liquidé en tant que tel. Donc cette partition est inservable en l'état.

Si le volume HAL 9000 est quand même bien monté sur ton Bureau de session de SierraBeta > alors tente la commande suivante dans le «Terminal» (copier-coller) :
Bloc de code: 
sudo bless --folder /Volumes/HAL\ 9000/System/Library/CoreServices
et ↩︎ --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe et derechef ↩︎

Cette commande appelle l'utilitaire bless ("bénir" - spécialisé dans la "bénédiction" des en-têtes de volumes pour y inscrire le chemin d'accès au boot_loader boot.efi de démarrage) > sur la cible du répertoire des CoreServices de la Bibliothèque-Système du volume HAL 9000 qui contient le boot.efi de cet OS. C'est la commande classique de restauration de la propriété "bootable" sur un volume.

La commande passée > re-démarre carrément ton Mac > et passé l'écran noir avant même le gong du Chime > tiens pressée la touche "alt" du clavier => est-ce que tu vois affiché ce coup-ci un volume HAL 9000 comme disque choisissable pour démarrer ?
----------------------​

Si tu échouais dans la manœuvre ci-dessus (c'est tout à fait présumable) > je te conseillerais 2 démarches successives :

- a) démarrer avec la combinaison de touches pressées ensemble ⌘⌥R (cmd alt R) => c'est le démarrage par internet, qui va connecter ton Mac au serveur de l'AppStore et faire télécharger dans un RAMDisk (disque virtuel créé ad-hoc en RAM) le dossier de démarrage d'une Recovery sur le Système de laquelle ton Mac va démarrer à la fin (affichage du logo d'un globe terrestre en rotation tout le temps du téléchargement - compte 10 bonnes minutes).

Une fois atteint le panneau des 4 Utilitaires OS X > lance l'«Utilitaire de Disque» (attention : c'est celui de l'OS d'usine de ton Mac, pas celui d'«El Capitan» à moins que 10.11 ne soit cet OS d'usine, si ta bécane est très récente). Si c'est l'«Utilitaire de Disque» "old school" => tu sélectionnes le disque entier de ton Mac et l'option "Réparer le disque" qui va tenter de réparer la Carte de partition GPT (je crois que tu as en plus un problème avec l'en-tête EFI de cette table de partition). Si c'est l'«Utilitaire de Disque» d'«El Capitan» > S.O.S. sur le disque entier du Mac.

=> vois si la réparation est annoncée réussie. Ne tente surtout pas de "Ré-installer OS X" avec l'autre option de la fenêtre : ce n'est pas le bon installateur qui serait téléchargé, mais celui de l'OS d'usine. Va plutôt au menu  tout en haut à gauche > Disque de démarrage > est-ce que tu peux choisir le volume HAL 9000 s'il est affiché ? Est-ce que tu peux re-démarrer dessus ?
---------------​

- b) dans tous les cas de figures (échec de a) ou pas) > re-démarre sur «Sierra» > télécharge depuis l'AppStore l'installateur d'«El Capitan» qui doit figurer dans tes achats > il va se retrouver dans les Applications mais va à la fin te proposer automatiquement une installation (sinon, double-clique l'installateur des Applications - s'il s'affiche automatiquement un panneau d'installation, sache que l'install ne démarre jamais toute seule) > choisis le volume HAL 9000 comme "destination" et lance la ré-installation (il ne s'agit que d'une restauration des fichiers du Système, qui ne touche pas le compte d'utilisateur, ni ses données, ni les applications tierces ajoutées).

=> à la fin, il y régulièrement re-démarrage automatique sur l'OS restauré, dont le volume a donc récupéré le bootable_flag et le chemin au boot.efi > cette restauration est susceptible de régler ton problème (à moins que tu n'aies un ennui résilient dans la carte de partition GPT). De plus, cette restauration restaure aussi la «Recovery HD» dans la foulée => un diskutil list à la fin devrait de montrer une partition Apple_Boot Recovery HD disk0s3.​

--------------------​
 
Dernière édition par un modérateur:
La première commande n'a pas permis de restaurer le disque dans l'écran de démarrage.
Le démarrage par Internet a permis de réparer le disque (en tout cas, selon l'utilitaire). Passé une première fois, il a affiché un étrange message dans une fenêtre d'alerte :
Bloc de code: 
Alerte
Système de fichier non reconnu
Mais la seconde fois, non. Par contre, un petit message en rouge s'affichait dans la console :
Bloc de code: 
Invalid Disk Label @ 980337430528: cksum mismatch
J'ai pu sélectionner le disque de démarrage, mais il a quand même redémarré sous Sierra. J'ai donc redémarré et utilisé "alt", et là j'ai encore sélectionné mon volume El Capitan, mais il a tout de suite affiché un panneau de sens interdit blanc sur fond noir. Après plusieurs secondes, il redémarre encore sous Sierra.
Une fois sous Sierra, l'utilitaire de disque estime que tout va bien.

diskutil retourne un résultat légèrement différent :
Bloc de code: 
/dev/disk0 (internal, physical):

  #:                       TYPE NAME                    SIZE       IDENTIFIER

  0:      GUID_partition_scheme                        *1.0 TB     disk0

  1:                        EFI EFI                     209.7 MB   disk0s1

  2:          Apple_CoreStorage HAL 9000                980.3 GB   disk0s2

  3:                 Apple_Boot Boot OS X               650.0 MB   disk0s3

  4:          Apple_CoreStorage SierraBeta              18.7 GB    disk0s4

  5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5

Je ne peux pas télécharger El Capitan car il me manque environ 600 mo d'espace sur la partition de Sierra. Je vais voir ce qu'il est possible de supprimer sans compromettre le système. Ironie du sort, c'est une fonction de Sierra, mais chez moi sur cette bêta, ça ne fonctionne pas (ça tourne, ça tourne, et après avoir transformé le Mac en autocuiseur, l'icône « Système » est grisée).

Pour l'instant, je fais une pause, je laisse la fenêtre mouliner à nouveau des fois que cette fois-ci je puisse libérer de l'espace « à la régulière ». Je pense dans la foulée faire une nouvelle remise à zéro de la NVRam et essayer une dernière fois de démarrer sur mon volume El Capitan. Si ça ne fonctionne pas, je me débrouillerai pour trouver de la place et réinstaller le système. J'avais en fait écarté rapidement cette solution car je ne pensais pas que c'était inhérent au système d'exploitation, mais quelque chose de plus profond qu'il fallait soit modifier « à la dure » soit carrément formater. C'est plutôt une bonne nouvelle si réinstaller El Capitan résout le problème. En attendant, c'est l'heure de dîner par chez moi, je file en cuisine.

Merci pour toute ton aide jusqu'à présent :)


@ Moonwalker, il faut croire que Siri a été la ressemblance de trop, HAL 9000 a pété les plombs et s'est suicidé :p

---------------------
Bon, j'ai pas pu m'empêcher de redémarrer une dernière fois. J'ai raté ma remise à zéro de la NVRam (un maj au lieu d'un alt, je crois :P), du coup il s'est chargé tout seul très vite… sous El Capitan. Tout semble aller comme sur des roulettes.
Mille fois merci ! Et j'espère que ce sujet permettra à d'autres personnes de s'en sortir :D
 
Dernière édition:
Quoique HAL 9000 ait récupéré le respect de l'instruction interdisant de nuire à un être humain en ne bootant pas (ce qui est la règle morale n°1 d'un Système logique) - tu peux quand même, dans ta session «El Capitan», re-télécharger un installateur 10.11 depuis l'AppStore et l'appliquer en direct au Système démarré. Ça peut apurer les choses...

Ta partition Recovery HD a récupéré un nom de volume : Boot OS X > il arrive que cet intitulé bizarre se substitue au nom canonique Recovery HD. Tu n'as qu'à répéter une commande :
Bloc de code: 
diskutil mount /dev/disk0s3
pour voir si un volume Recovery HD monte bien sur ton Bureau de session > si tu l'ouvres, s'il y a bien un dossier com.apple.recovery.boot principal > si tu l'ouvres un fichier boot.efi et un cache prelinkedkernel visibles (il y a un BaseSystem.dmg invisible graphiquement qui recèle le Système) => si tous ces éléments sont là > ta Recovery HD est a priori démarrable. Pour remasquer le volume Recovery HD :
Bloc de code: 
diskutil umount /dev/disk0s3

Avoir un clone (image-miroir démarrable) de ton volume HAL 9000 sur un DDE (voir le logiciel de clonage «Carbon Copy Cloner») te permettrait d'avoir a priori une copie démarrable du principal de tes données à un moment T (alternative : une sauvegarde Time Machine) > ce qui permet d'envisager ce type d'incidents logiques avec détachement quand il surviennent.
 
Lorsque je tape cette commande, un volume intitulé "Boot OS X" monte. À l'intérieur, trois dossiers (com.apple.boot.P, com.apple.recovery.boot, System). On y trouve bien un "prelinkedkernel" et "boot.efi" dans com.apple.recovery.boot, mais lorsque je tape cmd+r au démarrage, bien que mon disque de démarrage soit désormais de nouveau mon volume El Capitan, c'est le Recovery HD de Sierra qui se lance. À noter qu'il n'y a pas de BaseSystem.dmg qui s'affiche lorsque les fichiers cachés sont révélés.
Chose étrange, le volume s'est démonté tout seul alors que je tapais ce message, et quand je l'ai remonté, le dossier com.apple.boot.P s'est renommé en com.apple.boot.S.
J'ai téléchargé et tenté de réinstaller El Capitan via ma partition El Capitan, le processus d'installation s'arrête au bout de quelques minutes avec comme message :
Bloc de code: 
OS X n'a pas pu être installé sur l'ordinateur

Impossible de terminer la copie.

Quittez le programme d'installation pour redémarrer votre ordinateur puis réessayez.
Après avoir supprimé puis téléchargé le fichier d'installation à nouveau, toujours via le Mac App Store (peut-être était-il corrompu), le même problème se produit. Le SOS Disque est revenu à son diagnostic d'origine (can't unmount), et met en avant deux Invalid Disk Label cksum mismatch.
J'ai entre temps mis à jour ma sauvegarde Time Machine.
 
Yohmi a dit:
Après avoir supprimé puis téléchargé le fichier d'installation à nouveau, toujours via le Mac App Store (peut-être était-il corrompu), le même problème se produit
Cliquez pour agrandir...

Je ne pense pas qu'il y ait un problème relatif à l'installateur que tu as téléchargé depuis l'AppStore > je subodore qu'il y a un problème avec la partition de récupération «Recovery HD» localisée en disk0s3. Le message :

Yohmi a dit:
Invalid Disk Label cksum mismatch
Cliquez pour agrandir...

se laisse peut-être interpréter ainsi => « Invalid Disk Label » (Nom de Volume Invalide : l'intitulé "Boot OS X" au lieu de "Recovery HD") dû à une « cksum mismatch » (une invalidité de la somme de contrôle - checksum - et de l'allocation de blocs des fichiers décelée par l'utilitaire cksum). S'il manque le disque virtuel BaseSystem.dmg dans le dossier de boot com.apple.recovery.boot > peut-être aurait-on là raison de l'erreur de vérification de la somme des ressources > et par suite du changement de nom du volume.

De là à conjecturer que cette erreur au niveau de la «Recovery HD» soit responsable du plantage de ta ré-installation d'«El Capitan» : je suis tenté d'opérer cette extrapolation. Sachant qu'un installateur d'OS X commence toujours par mettre à jour la partition de secours collatérale de l'OS avant de restaurer l'OS lui-même > si le processus bloque sur la «Recovery HD» --> il avorte pour la restauration consécutive du volume HAL 9000.

Mais ce diagnostic tout conjectural doit intégrer en outre le fait que la partition disk0s2 de HAL 9000 supporte un format CoreStorage, qui est l'intercalement de 2 disques virtuels (un Physical Volume et un Logical Volume - avec une instance intermédiaire de pilotage : une Famille de Volumes Logiques) entre le container de blocs bruts de la partition disk0s2 et le système de fichiers jhfs+ terminal de HAL 9000.

Lorsqu'il en est ainsi, une relation logique se trouve établie avec la partition de récupération collatérale, en ce sens que le démarreur boot.efi de la «Recovery HD» sert de relai exécutif de démarrage pour l'EFI dans le boot de l'OS (même quand il n'y a pas de chiffrement du volume de ce dernier). Le dossier collatéral com.apple.boot.P recèle des caches de démarrage qui jouent exclusivement un rôle pour le boot du Système de l'OS en situation de CoreStorage. Cette utilisation de la partition de récupération comme relai de boot du Système de l'OS lorsqu'un format CoreStorage non-Chiffré se trouve greffé sur la partition d'OS X > me paraît un mécanisme relativement récent qui fait qu'il y a dépendance logique au démarrage du Système de l'OS par rapport à la partition de la récupération, en situation de CoreStorage.

Si je n'erre pas trop dans ces considérations > cela revient à dire qu'il existe une « sensibilité accrue » du démarrage de l'OS par rapport au dispositif logique de la «Recovery HD» en condition de CoreStorage - format que génère automatiquement l'installateur d'«El Capitan».

Lorsque tu t'es livré à un re-partitionnement du Volume Logique CoreStorage de HAL 9000 (ce qui est normalement très bien supporté), puis à une tentative avortée de récupération de l'espace de la nouvelle partition > il y a eu génération d'une partition disk0s4 qui a forcé une migration sur les blocs du système de fichiers de la «Recovery HD» > je conjecture qu'une erreur s'est produite à ce moment-là, qui a affecté le contenu des ressources de la «Recovery HD» > et par ricochet a compromis le mécanisme de démarrage du volume HAL 9000 solidaire de cette partition de par le dispositif du CoreStorage.

--------------------
​
Si tu as bien mis à jour ta sauvegarde Time Machine : je te propose plusieurs manœuvres hardies pour apurer la situation logique de ton disque que je pense toujours précaire et prédisposant au plantage du démarrage. Lesquelles ?

- a) la réversion logique de ton CoreStorage (qui est marqué : "revertible") --> ce qui libérerait provisoirement le volume HAL 9000 de toute solidarité logique de boot avec la partition de récupération disk0s3.

- b) la suppression de la partition disk0s3 Recovery HD et la récupération de son espace à la partition HAL 9000.

- b-bis) la recréation de la partition Recovery HD à partir des ressources de l'installateur d'«El Capitan» que tu as téléchargé.

- c) la ré-installation de l'OS de HAL 9000 via l'installateur : normalement, en cas d'absence de Recovery HD, le processus de ré-installation commence par la recréer (ce qui fait que l'étape b-bis est évitable) > car l'installateur d'«El Capitan» régénère a priori le format CoreStorage sur la partition de l'OS cible > il a donc besoin d'une Recovery HD collatérale qui va resservir de relai de démarrage de l'OS.​

--------------------
​
Si le programme que je viens de décrire t'agrée, alors voici comment faire [ banzaï ! ] :

- a) réversion du format CoreStorage de la partition disk0s2 --> tu passes la commande (copier-coller) :
Bloc de code: 
diskutil coreStorage revert 2A7E47FA-AF67-4890-8FB8-70C6183783D2
> cette commande appelle diskutil > la spécification cs = CoreStorage > le verbe revert (opérer la réversion) > l'UUID du Logical Volume HAL 9000.

Si tu obtiens le déroulement d'un affichage te disant que tout s'est déroulé normalement > alors il est impératif que tu re-démarres > car le kernel en usage n'a pas intégré la suppression du disk1 virtuel (celui du Volume Logique) et l'atterrissage du système de fichiers jhfs+ de HAL 9000 dans le container de blocs bruts de la partition disk0s2. Re-démarre avec "alt" éventuellement pour pouvoir choisir HAL 9000, ou mieux encore via le panneau du "Disque de démarrage" des Préférences Système.

- b) suppression de la partition de récupération disk0s3 et récupération de son espace à la partition disk0s2 --> tu passes d'abord la commande de destruction du système de fichiers de la «Recovery HD» :
Bloc de code: 
diskutil eraseVolume free NULL /dev/disk0s3
et si tu n'as pas de message d'erreur > tu enchaînes par la commande de réallocation du petit espace de 650 Mo à la partition disk0s2 :
Bloc de code: 
diskutil resizeVolume /dev/disk0s2 0b
qui devrait passer à la double condition qu'une bande de blocs de 650 Mo ne soit pas trouvée trop petite pour justifier un re-dimensionnement et que le système de fichiers jhfs+ de HAL 9000 passe le test de vérification. Si ce n'était pas le cas : re-démarrage sur «Sierra» > S.O.S. sur le volume HAL 9000 pour le réparer > re-démarrage sur «HAL 9000» > repasser la commande diskutil resizeVolumes /dev/disk0s2 0b.

- c) ré-installation directe d'«El Capitan» sur HAL 9000 (sans recréer spécifiquement au préalable la «Recovery HD») > l'installateur devrait te la re-créer en préalable (et une partition valide, ce coup-ci) > puis restaurer les fichiers du Système de ton OS => intéressant de vérifier si tout ce processus s'opère sans blocage cette fois...​

--------------------​
 
Tout s'est déroulé avec succès. En libérant disk0s02 de CoreStorage, j'ai pu effacer la partition défaillante Apple_Boot, réallouer cet espace à HAL 9000 et lancer la réinstallation d'El Capitan via HAL 9000, ce qui a dans la foulée recréé une partition Recovery HD toute neuve et toute propre. Avant de faire ça, j'avais effectué un clone sur Carbon Copy Cloner (je commence à me demander si Time Machine correspond vraiment au type de sauvegarde dont j'ai besoin, car si je n'avais pas eu ma partition Sierra, j'aurais été bien embêté avec mon Time Machine : j'ai essayé de démarrer dessus et ça n'a rien donné, je suis reparti directement sur HAL 9000). Il était alors impossible de créer un clone de la partition "Recovery HD". Après réinstallation du système, j'ai pu mettre à jour mon clone, cloner par la même occasion le volume "Recovery HD", et tous les diagnostics sont au vert.

C'est magique !

Mais, et c'est bien là l'ironie du sort, ce qui m'a entraîné dans toute cette histoire, c'est d'avoir essayé de redimensionner le volume CoreStorage sur lequel est installé ma bêta publique de Sierra afin d'avoir assez d'espace pour la mettre à jour. Me revoilà au même point, même si j'en ai appris beaucoup. Et je me demandais… est-il sensé d'utiliser les commandes non documentées qui permettent visiblement de redimensionner un volume CoreStorage ? Voire d'effectuer un reversion logique de la partition de Sierra ? Ou mieux vaut laisser tomber tout ça, supprimer cette partition trop petite une bonne fois pour toute, en recréer une plus grande et installer la bêta de Sierra dessus ?
 
Yohmi a dit:
C'est magique !
Cliquez pour agrandir...

Toi : une bonne fée s'est penchée sur ton berceau et t'a collé une cuiller en argent dans la bouche...​

Yohmi a dit:
est-il sensé d'utiliser les commandes non documentées qui permettent visiblement de redimensionner un volume CoreStorage ? Voire d'effectuer un reversion logique de la partition de Sierra ? Ou mieux vaut laisser tomber tout ça, supprimer cette partition trop petite une bonne fois pour toute, en recréer une plus grande et installer la bêta de Sierra dessus ?
Cliquez pour agrandir...

... par contre dès que tout roule, tu n'as qu'une envie : c'est de replanter le bazar (mais comme tu es verni > ça le refera de nouveau (eh ? c'est pas un programme, ça ?))​

--------------------​

Pour ce qui est des re-partitionnements via diskutil (l'«Utilitaire de Disque» est une interface graphique réduite pour ce binaire UNIX) > voici l'idée directrice.

L'espace complet de ton disque est interprété comme une série linéraire de blocs de 512 octets chacun, numérotés de 0 à n. Chaque partition du disque est une section de ces blocs, commençant au bloc n° tant et finissant au bloc n° tant (espace géré comme un répertoire de fichiers montable par un système de fichiers résidant sur l'en-tête de la partition). Carte de blocs, carte des partitions : tout est défini dans les fichiers de la table de partition GPT (GUID Partition Table) inscrite sur les 32 premiers blocs du disque.

Ce contexte brossé à gros traits > si tu re-partitionnes ta partition disk0s2 de 973 Go par exemple en un HAL 9000 réduit à 800 Go et un Untitled de 173 Go > voici ce qui se passe : le système de fichiers de la disk0s2 est réduit à 800 Go avec enregistrement de la modif dans la GPT > les 173 Go libérés sont toujours pris en queue de secteur de la partition (du point de vue de la numération des blocs), jamais en tête de secteur, car l'en-tête d'une partition porte l'ancrage fixe du système de fichiers et constitue un "point origine" inamovible. Donc les 173 Go de Untitled vont devenir une disk0s4 "en-dessous" de la disk0s2.

Et la «Recovery HD» de disk0s3 alors ? Elle est intercalée > elle va sauter ? Les 173 Go de blocs ne vont quand même pas "sauter" comme des moutons par-dessus sa barrière pour atterrir en-dessous d'elle (car la «Recovery HD» par principe reste "collée" par en-dessous à la limite basse de la partition de l'OS correspondant) ? - Non : une fois les 173 Go de blocs virés à du free_space entre la fin de la disk0s2 rétrécie à 800 Go et la disk0s3 de 650 Mo, le système de fichiers de la disk0s3 (Recovery HD) est cloné sur les 650 premiers Mo de blocs de départ de ce free_space, à coller la limite basse de la disk0s2 > puis son original est supprimé > puis les 173 Go de free_space désormais en-dessous de la «Recovery HD» clonée se voient assigner un système de fichiers jhfs+ sur leur en-tête, ce qui convertit cet espace de bloc en partition > avec enregistrement dans le GPT de tête du disque.

La partition disk0s4 Untitled de 173 Go est donc actuellement située pile en-dessus de la SierraBeta qui occupe le rang disk0s5 > peut-on additionner cet espace disk0s4 à celui de la partition disk0s5 ? Jamais directement sans détruire au préalable le système de fichiers de la partition basse (SierraBeta), car il faut toujours d'abord qu'un espace de bloc soit viré au statut de free_space (blocs sans système de fichiers gestionnaire) pour pouvoir être ajouté à partir du bas à une partition du dessus > dans ce cas, le système de fichiers de la partition du-dessus est étiré à une taille de gestion de blocs qui comprend le nombre des blocs libres du dessous.

Tu me suis toujours ? Il faut donc dans ma descritpion que tu détruises le système de fichiers de SierraBeta pour que l'espace de cette partition soit ajouté depuis le bas à l'espace de la partition du dessus Untitled dont le système de fichiers ancré en tête de cette partition reste fixe en terme d'origine. Mais alors (dis-tu) : et mon OS «Sierra» ? Et mes données ? - Eh oui ! elles seront détruites en même temps que le système de fichiers, car seul ce système de fichiers interprète les écritures des blocs comme des fichiers relevant de répertoires. Plus de système de fichiers > plus de fichiers > écritures de blocs ininterprétables = disponibles pour l'effacement et la ré-inscription.

Alors que faire ? Eh bien ! quelque chose d'analogue à ce que le Système fait pour permettre au système de fichiers de la «Recovery HD» avec ses données d'échapper à la destruction lors d'un re-partitionnement : tu clones en manuel («CCC» est ton ami) les données de SierraBeta dans Untitled en préalable, avant de supprimer SierraBeta puis de dilater Untitled de cet espace libre => à l'arrivée, le système de fichiers Untitled gère les données qui étaient écrites dans SierraBeta : un OS avec un compte utilisateur comportant tes données. Mais tu te retouves avec une partition Untitled de 200 Go, que tu peux renommer a la mano > SierraBeta.

--------------------
​
Comme tu es manifestement du style « verni » (càd. le genre qui passe à travers la pluie battante sans se mouiller davantage les plumes qu'un canard (ce qui t'est facile, car tu es un « bipède sans plumes »)) > si tu as envie de réaliser cette manœuvre mirifiquement alambiquée (mais en fait totalement sûre) > tu n'as qu'à fournir 2 renseignements :

a) un copier-coller des 2 tableaux actuellement retournés par les commandes (à repasser séparément) :
Bloc de code: 
diskutil list
diskutil cs list
(la seconde, car la ré-installation d'«El Capitan» t'a recollé un nouveau CoreStorage, sois en certain...) ;

b) l'indication de la taille à laquelle tu veux voir réduire l'actuelle partition disk0s2 HAL 9000 de 973 Go : 800 Go ? 850 ? => à toi de dire...​
 
Dernière édition par un modérateur:
Je crois en ma bonne étoile et je tente le Super Banco :p

Cette histoire de volumes qui s'empilent comme des rugbymen, j'avoue que ça me dépasse. Vivement qu'on passe en APFS, tiens :D

En attendant, sur notre bon (bientôt) vieux CoreStorage…
Bloc de code: 
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage HAL 9000                980.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:          Apple_CoreStorage SierraBeta              18.7 GB    disk0s4
   5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS HAL 9000               +980.0 GB   disk1
                                 Logical Volume on disk0s2
                                 57C3AB23-6E84-4C00-A22D-E6E93F03A461
                                 Unencrypted
/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS SierraBeta             +18.3 GB    disk2
                                 Logical Volume on disk0s4
                                 FCB96808-6161-45ED-BAC1-78C18CAC9683
                                 Unencrypted
Bloc de code: 
diskutil cs list
CoreStorage logical volume groups (2 found)
|
+-- Logical Volume Group F48774C8-22D5-4D84-8E41-B0E1C6F0D14A
|   =========================================================
|   Name:         SierraBeta
|   Status:       Online
|   Size:         18699997184 B (18.7 GB)
|   Free Space:   10178560 B (10.2 MB)
|   |
|   +-< Physical Volume AF281840-6FBF-42ED-A605-75FAF540B7E1
|   |   ----------------------------------------------------
|   |   Index:    0
|   |   Disk:     disk0s4
|   |   Status:   Online
|   |   Size:     18699997184 B (18.7 GB)
|   |
|   +-> Logical Volume Family 10BD5337-6312-49F7-8474-ED4C831CA649
|       ----------------------------------------------------------
|       Encryption Type:         None
|       |
|       +-> Logical Volume FCB96808-6161-45ED-BAC1-78C18CAC9683
|           ---------------------------------------------------
|           Disk:                  disk2
|           Status:                Online
|           Size (Total):          18337497088 B (18.3 GB)
|           Revertible:            Yes (no decryption required)
|           LV Name:               SierraBeta
|           Volume Name:           SierraBeta
|           Content Hint:          Apple_HFS
|
+-- Logical Volume Group 30CB58C9-6BAD-4096-8629-748E3A5129C3
    =========================================================
    Name:         HAL 9000
    Status:       Online
    Size:         980345823232 B (980.3 GB)
    Free Space:   18882560 B (18.9 MB)
    |
    +-< Physical Volume 99762B9D-7EB3-487C-A595-632CC0C97951
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     980345823232 B (980.3 GB)
    |
    +-> Logical Volume Family C6115F89-DA6F-4686-A24E-97E25086C093
        ----------------------------------------------------------
        Encryption Type:         None
        |
        +-> Logical Volume 57C3AB23-6E84-4C00-A22D-E6E93F03A461
            ---------------------------------------------------
            Disk:                  disk1
            Status:                Online
            Size (Total):          979974619136 B (980.0 GB)
            Revertible:            Yes (no decryption required)
            LV Name:               HAL 9000
            Volume Name:           HAL 9000
            Content Hint:          Apple_HFS

Je pense que passer HAL 9000 de 980 à 965 Go sera une baisse suffisante, je préfère avoir de la place sur mon volume de travail (et je suis un petit joueur, tout à fait) :)
 
Bon : tout est comme attendu.

Tu veux réduire ton HAL 9000 à 965 Go > ce qui produirait une partition provisoire Untitled de 15 Go. Alors, la question est : cet espace est-il suffisant pour y cloner la taille des données actuellement contenues dans le volume SierraBeta de 18,7 Go (car ce qui est cloné est la taille des données contenues, pas la taille du volume contenant) ?

Il y a des chances que oui, vu la faible taille de SierraBeta (18,7 Go > ah ! on peut dire que tu serres le jeu en mode beta... (petit joueur, va !)). Pour être tout à fait sûrs, tu n'as qu'à passer dans le «Terminal» la commande (purement informative) :
Bloc de code: 
df -H
--> df (display_free_space) va retourner le tableau de toutes les partitions de ton disque, avec la proportion espace occupé / libre en grandeurs "humainement lisibles" (GB) --> tu n'as qu'à poster ce tableau pour qu'on voit ce qu'il en est de SierraBeta.
 
df -H a retourné ceci :
Bloc de code: 
Filesystem                          Size   Used  Avail Capacity   iused     ifree %iused  Mounted on
/dev/disk2                           18G    12G   5.9G    68%   3034795   1442131   68%   /Volumes/SierraBeta
Donc à 12 Go, ça passe sur un Untitled de 15 Go :)
 
Alors voici le premier jeu de manœuvres > je pense qu'il est plus prudent de commencer par une réversion des 2 formats CoreStorage présents sur la partition disk0s2 (volume HAL 9000) et disk0s4 (volume SierraBeta).

Parce que, comme tu t'en es aperçu, les re-dimensionnements de partitions portant des Groupes de Volumes Logiques, même s'il sont supportés et exécutables en ligne de commande, sont toujours moins francs du collier que ceux de partitions portant un système de fichiers standard jhfs+.

- a) réversion du CoreStorage de la partition disk0s2 (volume HAL 9000) :
Bloc de code: 
diskutil coreStorage revert 57C3AB23-6E84-4C00-A22D-E6E93F03A461
--> une fois l'affichage décrivant l'opération achevé > re-démarre par prudence (toujours sur ton HAL 9000) afin d'éviter que le kernel ne s'emmêle les pinceaux dans sa gestion des volumes montés.

- b) réversion du CoreStorage de la partition disk0s4 (volume SierraBeta) :
Bloc de code: 
sudo diskutil coreStorage revert FCB96808-6161-45ED-BAC1-78C18CAC9683
(avec password à l'aveugle comme pour la commande bless antérieure). Il est possible d'opérer la réversion d'un CoreStorage sans être démarré sur son Système > je t'ai mis un sudo au cas où il y aurait un problème de permission à opérer d'un Système indépendant > à complétion de l'affichage, pareil : re-démarre (toujours sur ton HAL 9000) pour que le kernel soit bien à jour des volumes montés.

=> une fois ces commandes passées, reposte le tableau retourné par un diskutil list histoire de vérifier si tout est bien en ordre. Si oui > ce sera bon pour le deuxième jeu de manœuvres.​
 
Voilà ce que j'obtiens :

Bloc de code: 
/dev/disk0 (internal, physical):

  #:                       TYPE NAME                    SIZE       IDENTIFIER

  0:      GUID_partition_scheme                        *1.0 TB     disk0

  1:                        EFI EFI                     209.7 MB   disk0s1

  2:                  Apple_HFS HAL 9000                980.3 GB   disk0s2

  3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

  4:                  Apple_HFS SierraBeta              18.7 GB    disk0s4

  5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
 
Magnifique ! Tout marche sur des roulettes...

Pour le repartitionnement de HAL 9000 à présent : est-ce que tu serais d'accord pour le ramener à 960 Go, ce qui permettrait de créer une partition Untitled de 20 Go ?

- ça me semble plus prudent qu'un simple 15 Go et ça permettrait, au lieu d'utiliser «Carbon Copy Cloner» pour le clonage suivant, d'utiliser encore un utilitaire UNIX (qui est sensible au proportions de taille entre une partition "source" et une de "destination" --> une "destination" de 20 Go pour une "source" de 18,7 : ça lui irait parfaitement...).​
 

Sujets similaires

D
10.11 El Capitan Le processus S.O.S a échoué [...] une erreur interne s'est produite
Réponses
19
Affichages
3K
macOS
Darkchymere
D
B
10.13 High Sierra Comment trouver l'extension qui bloque le démarrage de mon Imac ?
Réponses
5
Affichages
2K
macOS
Sly54
Sly54
F
10.11 El Capitan Clé de démarrage El Capitan impossible à créer, Install ESD.dmg qui semble poser problème
Réponses
26
Affichages
4K
macOS
Locke
Locke
B
macOS Sonoma Macbookair T2 reboot systématiquement en récupération internet
Réponses
4
Affichages
445
macOS
Benbens19
B
O
macOS Monterey Aide Fusion Partitions
Réponses
8
Affichages
1K
macOS
Locke
Locke
Haut Bas