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

[Membre supprimé 1060554]

Le tableau de la NVRAM est toujours abstrus > l'intéressant dans ton cas est ceci :

efi-boot-device <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>5ABE1D7A-8812-46EB-AA1F-ABFEA766BEDE</string></dict></dict><key>BLLastBSDName</key><string>disk0s4</string></dict></array>%00

que je te décode en clair :

l'efi-boot-device est le device (container-disque d'une partition) où l'EFI doit accéder automatiquement en mode boot > là, le chemin au répertoire des CoreServices renseigné par le blessing > lui permet d'aller exécuter le boot_loader: boot.efi avant de couper en tant que programme, et de laisser le boot.efi charger le cache de démarrage.

L'adresse du device est la partition disk0s4 et son UUID le 5ABE1D7A-8812-46EB-AA1F-ABFEA766BEDE > càd. la partition de ton OS Sierra qui s'est arrogé la préférence automatique de boot et qui la garde.

Est-ce que tu peux, dans le «Terminal» de n'importe lequel de tes OS, passer la commande :

csrutil status

et poster le retour ? > s'il était mentionné :

System Integrity Protection status: enabled.

alors je comprendrais l'échec de mon option précédente --setBoot > mon expérience m'a montré que le SIP inauguré avec «E Capitan» et conservé avec «Sierra» ne se contente pas de verrouiller les répertoires-Système critiques de l'OS > mais verrouille aussi des rubriques de la NVRAM contre des tentatives d'édition, dont la rubrique efi-boot-device.

Selon ton retour, il pourrait être envisageable de désactiver le SIP s'il y avait lieu, pour manipuler l'adresse de boot automatique de la NVRAM.

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

Les informations éclairées que tu avais donné dans ton premier message révèlent que le dossier de boot de ta partition disk0s3 (ci-devant Recovery HD) est flingué de ses organes logiques principaux de démarrage. C'est la raison pour laquelle tu as eu une mention de Invalid DiskLabel @212735897600 : cksum mismatch (invalidité du nom de volume, découlant d'une inadéquation des ressources attendues).

En l'état, cette partition flinguée est non seulement inutile (in-démarrable), mais nocive, car elle interdit une restauration du Système. Il faut donc s'en débarrasser. Ce que tu fais en 2 commandes :

- a) d'abord :

sudo diskutil eraseVolume free NULL /dev/disk0s3

pour virer la partition Recovery à de l'espace libre.

- b) puis :

diskutil resizeVolume /dev/disk0s2 0b

pour récupérer les 650 Mo d'espace libre à la partition de Ouwéis SSD.​

Un petit re-démarrage pour fixer la choses.

Il ne te restera plus qu'à ré-installer le «El Capitan» de ton volume Ouwéis SSD en re-téléchargeant un installateur depuis l'AppStore (depuis ta session Ouwéis SSD pour que l'installateur soit lançable en direct) et en le déclenchant à destination du même volume > cette restauration du Système va te re-créer la Recovery HD manquante (et une valide ce coup-ci).

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

 

[Dark-mac]

D'accord je comprend (légèrement) mieux le texte de la NVRAM maintenant.

Oui le SIP est activé :

➜  ~ csrutil status
System Integrity Protection status: enabled.

Les 650 Mo d'espace libre ont été récupérés. Maintenant je vais mettre à télécharger l'installateur de El Capitan, ce qui risque de prendre un peu de temps, entre 2 et 3 heures probablement, pour l'instant l'App Store m'indique 2H restantes mais ça va surement augmenter.

 

[Dark-mac]

C'est bon, réinstallation de El Capitan effectué ! Merci infiniment macomanic !
Juste au cas où j'ai lancé "diskutil list" et "diskutil cs list" mais je ne crois pas qu'il y ai un de problème, je met quand même le résultat ici :

➜  ~ 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_CoreStorage Ouwéis SSD              212.7 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                  Apple_HFS Sierra                  36.8 GB    disk0s4
   5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Ouwéis SSD           +212.4 GB   disk1
                                 Logical Volume on disk0s2
                                 E10BE254-2A2A-492B-9311-85B861DC589D
                                 Unencrypted

➜  ~ diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 2B0306C6-5BA1-4159-A27A-2C94D2D22182
    =========================================================
    Name:         Ouwéis SSD
    Status:       Online
    Size:         212740096000 B (212.7 GB)
    Free Space:   18890752 B (18.9 MB)
    |
    +-< Physical Volume C3E014CF-2EA7-4BDF-AA4E-6E3249E1E691
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     212740096000 B (212.7 GB)
    |
    +-> Logical Volume Family D0D3EF9C-22C7-4785-A558-19A43A9DCB1F
        ----------------------------------------------------------
        Encryption Type:         None
        |
        +-> Logical Volume E10BE254-2A2A-492B-9311-85B861DC589D
            ---------------------------------------------------
            Disk:                  disk1
            Status:                Online
            Size (Total):          212368883712 B (212.4 GB)
            Revertible:            Yes (no decryption required)
            LV Name:               Ouwéis SSD
            Volume Name:           Ouwéis SSD
            Content Hint:          Apple_HFS

 

[Membre supprimé 1060554]

Tout est en ordre.

Mais tu dois prendre en compte la donne suivante : l'installateur d'«El Capitan» t'a recollé un CoreStorage > dès lors qu'un format CoreStorage neutre (ni Chiffrement via «FileVault», ni Fusion Drive ici - lesquels requièrent tous deux aussi un CoreStorage) est greffé sur la partition disk0s2 > les conditions de démarrage du volume Ouwéis SSD passent par le relai du boot_loader: boot.efi du dossier com.apple.recovery.boot de la Recovery HD, avec des caches dédiés dans un dossier annexe com.apple.boot.P. Qu'il y ait un blème sur le volume de cette Recovery HD > tu ne peux plus démarrer le volume de ton OS et tu ne peux pas non plus démarrer le Système de la Recovery HD (enfin la présence d'une «Recovery HD» ayant perdu son nom de volume bloque un installateur déclenché en mode externe).

C'est ce qui t'est arrivé, et c'est ce qui était arrivé au créateur de ce fil Yohmi.

Ce me semble une implémentation récente du fonctionnement du CoreStorage que je n'avais pas relevée antérieurement et qui (de mon point de vue) rend tout à fait dangereux le maintien de ce format neutre (parfaitement inutile en l'état) sur le volume-Système.

Si tu veux te débarrasser de ce format (qui supporte encore ici la réversion) > passe la commande :

diskutil coreStorage revert E10BE254-2A2A-492B-9311-85B861DC589D

et, à complétion, re-démarre ton Mac.

Si tu veux inscrire une préférence de boot automatique sur ton volume Ouwéis SSD > je présume que passer par le panneau Disque de démarrage des Préférences Système > sélectionner le volume affiché Ouwéis SSD > doit être capable de manipuler la NVRAM en ce sens, même avec le SIP activé. Si ce n'était pas le cas > tu n'as qu'à faire signe...

 

[Dark-mac]

Oui en passant par le panneau Disque de démarrage dans Préférences Système je peux choisir le disque de boot, que j'ai mis sur Ouwéis SSD actuellement. Pour l'instant je préfère garder le CoreStorage puisque, vu que le nouveau système de fichiers APFS sera pour 2017 et comme je fais toujours toutes les mises à jour disponible, je préfère garder le CoreStorage pour l'instant pour ne pas avoir de problèmes lors de la migration de HFS+ vers APFS.