10.11 El Capitan MAJ & Etiquette de disque non valide

[Membre supprimé 1060554]

Salut kranker

«SuperDuper!» n'a jamais géré le clonage de la «Recovery HD» - quel que soit le format du volume d'accueil où est cloné l'OS.

«CCC» gère le clonage de la «Recovery HD», à condition que le volume d'accueil ne soit pas un Volume Logique CoreStorage (non-chiffré > chiffré > Fusion Drive).

C'est que, pour créer la «Recovery HD», il faut commencer par re-dimensionner (réduction de 650 Mo) le volume d'accueil > afin d'exporter une nouvelle partition de 650 Mo. Quand le volume d'accueil est un Volume Logique CoreStorage (et pas un volume standard JHFS+) > le redimensionnement demande déjà une commande spécifique (mais je ne pense pas que ça aurait gêné Mike Bombich).

C'est surtout, comme j'ai tenté de l'expliquer, qu'une partition CoreStorage est flanquée d'une partition « booter » : Apple_Boot Boot OS X de 134 Mo déjà en place. Créer à la place une Recovery HD de plus grande taille (650 Mo) > tout en clonant dans le volume de cette Recovery HD le dossier du « booter » (com.apple.Boot.S ou P) > et en bénissant pour finir ce volume pour que le chemin inscrit sur son en-tête pointe au dossier du « booter » du CoreStorage et plus au dossier du Recovery OS => c'est là que Bombich a jeté l'éponge.

En résumé : utiliser un installateur de macOS pour faire se créer la Recovery HD en queue de HDD lorsqu'il existe un CoreStorage Fusion Drive.

--------------------

Que te renvoie un :
diskutil list

=> la réponse est déjà donnée au message #22.

 

[Invité]

…

En résumé : utiliser un installateur de macOS pour faire se créer la Recovery HD en queue de HDD lorsqu'il existe un CoreStorage Fusion Drive.

J'ai pas suivi la solution… :shy:

 

[Membre supprimé 1060554]

J'ai pas suivi la solution…

Rhâââ ! - l'ascèse du samedi (dis ! manche...)-

- 1° Dispositif logique du HDD après création à vide du Fusion Drive (message #18).

/dev/disk1 (internal, physical):
#:                  TYPE NAME           SIZE       IDENTIFIER
0: GUID_partition_scheme               *1.0 TB     disk1
1:                   EFI EFI            209.7 MB   disk1s1
2:     Apple_CoreStorage Fusion Drive   999.9 GB   disk1s2
3:            Apple_Boot Boot OS X      134.2 MB   disk1s3

=> il faut noter qu'en 3è partition existe le « booter » --> 3: Apple_Boot Boot OS X 134.2 MB disk1s3 qui permet au Physical Volume importé sur la partition précédente --> 2: Apple_CoreStorage Fusion Drive 999.9 GB disk1s2 de jouer son rôle d'exportation du Volume Logique de synthèse du Fusion Drive.

----------​

- 2° Dispositif logique du HDD après installation "clean" d'«El Capitan» par l'installateur Install OS X El Capitan.app dans le Volume Logique du Fusion Drive (message #22) :

dev/disk1 (internal, physical):
#:                  TYPE NAME           SIZE       IDENTIFIER
0: GUID_partition_scheme               *1.0 TB     disk1
1:                   EFI EFI            209.7 MB   disk1s1
2:     Apple_CoreStorage Fusion Drive   999.9 GB   disk1s2
3:            Apple_Boot Recovery HD    650.0 MB   disk1s3

=> il faut noter qu'en 3è partition existe désormais une «Recovery HD » --> 3: Apple_Boot Recovery HD 650.0 MB disk1s3 de 650 Mo là où existait auparavant la partition du « booter » --> 3: Apple_Boot Boot OS X 134.2 MB disk1s3 de 134 Mo.

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

Cela signifie-t-il que la «Recovery HD» s'est substituée à la partition « booter » en la supprimant carrément ? - si cela était le cas > la bande CoreStorage --> 2: Apple_CoreStorage Fusion Drive 999.3 GB disk1s2 (Physical Volume n°2 du CoreStorage Fusion Drive) n'aurait plus de "déclencheur" logique de sa fonction d'exportation du Volume Logique de synthèse du Fusion Drive. Résultat ? --> le Volume Logique unique ne pourrait pas se trouver monté.

Les ingénieurs de la  ont créé une solution par hybridation : le volume Recovery HD en disk1s3 sert à 2 fonctions =>

- d'une part, il recèle l'ancien dossier (cloné) du « booter » = com.apple.Boot.P ;

- d'autre part et en parallèle, il recèle le dossier (standard) contenant le Recovery OS = com.apple.recovery.boot ;

- l'en-tête (header) du volume Recovery HD est modifié au niveau du « blessing » : le blessing pointe sur le « booter » du CoreStorage (dans le dossier spécifique com.apple.Boot.P) > et plus sur le « boot_loader : boot.efi » du Recovery OS (dans le dossier standard com.apple.recovery.boot).​

Résultat : le volume Recovery HD joue le rôle prioritaire de « booter » de la bande CoreStorage --> 2: Apple_CoreStorage Fusion Drive 999.3 GB disk1s2 - c'est sa fonction logique régulière en configuration CoreStorage > il joue le rôle seulement optionnel de volume du Recovery OS à la seule condition qu'on démarre en pressant les touches ⌘R (ce qui fait "échapper" le « booter » prioritaire dans ce volume = dossier com.apple.Boot.P > et aiguille l'EFI sur le Recovery OS = le dossier com.apple.recovery.boot).

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

On comprend accessoirement pourquoi, dès qu'il existe un CoreStorage sur la partition précédant celle de la Recovery HD, aucun volume Récupération 10.x n'est plus affiché à l'écran du boot_manager (touche "alt"). C'est parce que le boot_manager (sélecteur de volumes démarrables de l'EFI) ne "voit" plus le volume Recovery HD comme un volume de récupération (un volume de démarrage d'un Recovery OS) > mais le "voit" comme un « booter » de Volume Logique CoreStorage. C'est à cause du « blessing » sur le header du volume qui pointe au dossier « booter » : com.apple.Boot.P. En conséquence, le boot_manager affiche un volume qui porte l'intitulé du Volume Logique du CoreStorage (Macintosh HD par défaut). Ce volume affiché n'est pas le Volume Logique lui-même (car ce dernier n'est pas encore exporté à partir du Physical Volume de la partition supérieure) > c'est le volume de la Recovery HD lui-même et lui seul > mais volume de la Recovery HD interprété non comme volume d'un Recovery OS > mais volume du « booter » du Volume Logique CoreStorage.

En résumé : la complexe opération d'injection de la fonction « booter » de CoreStorage dans le volume Recovery HD pour créer un volume à fonction hybridée (une espèce d'exploit logique des ingénieurs de la  à l'époque de «Lion 10.7» : époque de la création de cette solution) > cette opération a fait reculer Mike Bombich qui a renoncé à l'implémenter dans son logiciel «Carbon Copy Cloner». Donc s'en remettre au Programme d'Installation des installateurs de macOS - parfaitement équipé pour mener à bien cette opération sophistiquée.

 

[kranker]

C'est super pointu tout ça !

Donc quand je restaure un backup sur une partition saine FusionDrive, SuperDuper laisse tranquil Recovery HD et je ne devrais pas avoir de problème au démarrage ou dans des tentatives ultérieures de récupération Time Machine ?

Pour être sûr, qu'elle est le meilleur moyen d'assurer ses arrières quand on a fusion drive ? Un backup avec un installer dessus et un time machine ?

Actuellement j'ai un gros DD externe avec une partition Time Machine et une partition Clone + un autre disque externe avec uniquement un Clone. Le premier pourrait m'assurer d'avoir un Clone up to date, si je programme des updates la nuit. Il est en mesure de se mettre ne veille et de ne pas faire de bruit quand il n'est pas utilisé alors que le deuxième est juste alimenté en USB et tourne en continu donc je ne le laisse pas branché.

 

[Membre supprimé 1060554]

Donc quand je restaure un backup sur une partition saine FusionDrive, SuperDuper laisse tranquil Recovery HD et je ne devrais pas avoir de problème au démarrage ou dans des tentatives ultérieures de récupération Time Machine ?

La réponse est : oui.

qu'elle est le meilleur moyen d'assurer ses arrières quand on a fusion drive ? Un backup avec un installer dessus et un time machine ?

Effectivement : c'est la "totale" --> tu peux (par exemple) démarrer sur ton clone et s'il le fallait relancer ton installateur directement pour restaurer le système ; ou, disques ré-initialisés, recréer un Fusion Drive > ré-installer (avec re-création de la Recovery HD ; ou récupérer simplement ta sauvegarde Time Machine etc. Bref : toutes les variantes sont possibles.

Note encore que : à supposer que tu aies besoin de recréer ton Fusion Drive après déconstruction > théoriquement la Recovery HD en disk1s3 peut rester en place : il te suffit de ne ré-initialiser que le SSD > reformater seulement la partition disk1s2 du CoreStorage du HDD > recréer un Fusion Drive vide à partir des 2 partitions disk0s2 & disk1s2. Le programme diskutil saura ré-injecter un booter ad hoc dans la Recovery HD préservée (l'ancien booter étant supprimé à la suppression du CoreStorage Fusion Drive) => il ne te reste alors qu'à re-cloner ou à récupérer ta sauvegarde TM dans le Volume Logique vide du nouveau Fusion Drive (en résumé : tu t'épargnes la phase "ré-installation clean" préalable - requise seulement si tu as supprimé la Recovery HD en ré-initialisant le HDD au lieu de ne faire que reformater sa partition-Système disk1s2).

Ton utilisation de tes DDE de sauvegarde m'a l'air au point. En somme : tu es paré.

 

[Invité]

J'avais bien compris la démonstration.
C'est l'utilisation de "l'installeur Mac Os" qui me titillait.
Juste un petit truc encore, quand le FD est constitué de 2 disques, à priori il y a un booter créé sur l'un des disque et un Recovery sur l'autre, non ?

 

[Membre supprimé 1060554]

quand le FD est constitué de 2 disques, à priori il y a un booter créé sur l'un des disque et un Recovery sur l'autre, non ?

- lors de la création formelle du CoreStorage Fusion Drive (via diskutil) > il y a 2 booters du même type (Apple_Boot Boot OS X 134 Mo) en partition n°3 de chaque disque (SSD & HDD).

- c'est uniquement si (et seulement si) une version de macOS est installée [réglementairement : soit via un installateur Install macOS [OS X] VersionOS.app] dans le Volume Logique résultant > que la partition booter du HDD est convertie en partition Recovery HD tenant un double emploi : booter primaire > Recovery OS secondaire.​

=> pas d'installation protocolaire de macOS dans le Volume Logique > pas de Recovery HD en n°3 du HDD. Bref : le booter précède logiquement la Recovery HD sur le HDD > et à sa création la Recovery HD récupère le dossier (et la fonction primaire) du booter (la fonction Recovery OS passant au plan optionnel = ⌘R). Ce n'est qu'en l'absence de CoreStorage que la partition Recovery HD joue le rôle primaire de partition du Système de secours.

 

[Invité]

OK, j'avais pas fait gaffe à la création du FD, et pas vu non plus que l'instal d'OsX transformait le booter.
Et à vrai dire je me demandais pourquoi il y avait 2 "Apple_Boot Boot OS X" de taille différente sur mes disques. J'ai la réponse !
J'en conclu alors, comme j'ai 2 SSD que c'est celui qui porte le "petit" booter qui est désigné comme cache du FD.