Zzozo
Les choses à faire, dans l'ordre, sont donc : cloner mon système, démarrer dessus, formater mon disque interne, recréer la partition de récupération Recovery HD (cela me semble plus simple de télécharger l'installateur plutôt que de faire cela manuellement), cloner à rebours dans le nouveau volume vide du Mac et enfin chiffrer le disque ? Et pas chiffrer avant de réinjecter mon système ?
Oui : c'est le sens global de la manœuvre. Tu l'as bien compris.
----------
Tiens ! je vois que
Jean - un matinal lui aussi
vient de réponde dans ce fil. Ce qui me donne l'occasion d'une glose estivale
Je ne suis pas sûr que la partition Recovery disparaisse.
Je prends les paris que si. Pour la raison suivante :
Étant donné qu'il existe un
CoreStorage, chiffré de surcroît, sur la partition de l'OS, en voici la conséquence : le volume
Recovery HD de la partition de secours a été promu, de la fonction basique de volume du
Recovery OS, à la fonction prioritaire de «
booter » du
Volume Logique (verrouillé dans le cas présent) du système de stockage
CoreStorage.
Pour l'explication détaillée de cette conversion logique > je préfère renvoyer à ce fil pour ne pas m'étendre dans la dimension du discours : ☞
Espace de récupération en 10.11 El Capitan☜ (message
#19).
La conséquence de cette conversion de fonction prioritaire du volume
Recovery HD (de volume de secours à volume du booter) est nécessairement la suivante : si l'on passe dans le «
Terminal» d'un Système indépendant (ce sera le clone du DDE ici) une commande de déconstruction du
Groupe de Volume Logique CoreStorage --> du genre :
Bloc de code:
diskutil coreStorage deleteLVG F77FCEE5-FF4D-41C0-9E3A-F784511ACA95
(où la cible est l'
UUID du
Logical Volume Group) => alors cette commande de destruction n'adresse pas la pile de disques virtuels échaffaudée sur la partition
disk0s2 comme s'il s'agissait d'un conteneur "solitaire" (auto-suffisant) > mais également la «
boot_helper_partition » de ce dispositif
CoreStorage qui en est entièrement "solidaire" : la partition
Recovery HD en tant qu'elle joue le rôle prioritaire de «
booter » du
CoreStorage.
En résultat : la
déconstruction du
CoreStorage implique la
suppression du «
booter » du
CoreStorage : il s'agit d'une
désintallation complète du dispositif.
- Il est vrai que le « booter » du CoreStorage, rigoureusement parlant, est un dossier com.apple.Boot.S recelé dans le volume Recovery HD, et voisinant avec le dossier com.apple.recovery.boot qui recèle le Recovery OS. On pourrait donc imaginer qu'un processus de déconstruction pointilleux du CoreStorage ne supprimerait que le dossier du « booter » com.apple.Boot.S dans le volume Recovery HD > et pas la partition toute entière.
- Certes ! Mais comme la déconstruction d'un Groupe de Volume Logiques implique la destruction de l'OS installé dans le volume terminal Macintosh HD (résidant tout en haut de la pile du CoreStorage, en tant qu'hôte du Volume Logique) > elle implique logiquement la destruction de toutes les dépendances logiques de l'OS - fonction auxiliaire de récupération y compris.
- Avec la suppression du CoreStorage enveloppant la suppression de l'OS terminal > c'est donc la suppression des 2 dépendances logiques : « booter » du CoreStorage + récupération de l'OS qui se trouve donc impliquée.
Ce raisonnement (qui peut paraître alambiqué) m'amène a conjecturer la
suppression en concomitance de la partition
Recovery HD et du dispositif
CoreStorage /
macOS. Je prévois comme résultat de la commande le tableau que voici :
Bloc de code:
/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 Untitled 250.9 GB disk0s2
