Comme je le disais 2 posts plus haut j'ai appliqué la commande que tu m'avais indiquée pour changer le N° de build du clone. IL semble donc que ça a marché mais il n'est toujours pas démarrable depuis mon iMac
10.12 Sierra Nouvel iMac et incompatibilités
- Créateur du sujet kinon
- Date de début
M
Membre supprimé 1060554
Invité
Oui : le n° de build a bien été édité. Mais ça ne rend pas pour autant le clone démarrable.
Le facteur à discriminer est donc ailleurs. Mais où ? - je n'ai pas d'idée pour le moment.
Le facteur à discriminer est donc ailleurs. Mais où ? - je n'ai pas d'idée pour le moment.
Comme je le disais précédemment j'avais déjà appliqué le commande pour changer le N° de build du clone, il semble que cela ait fonctionné mais je ne peux toujours pas démarrer dessus depuis mon iMac
Je ne sais pas pourquoi de temps en temps les messages que je viens d'éditer disparaissent... je les reposte et ils réapparaissent...
Je ne sais pas pourquoi de temps en temps les messages que je viens d'éditer disparaissent... je les reposte et ils réapparaissent...
M
Membre supprimé 1060554
Invité
...et pour moi > quand une réponse comme la tienne au message #41 tombe juste en terminaison de page > j'ai une alerte mais je ne peux pas voir la réponse à moins que je ne poste un pseudo-message derrière comme un simple .
Donc ma réponse était au message #42 où j'ai édité mon . initial qui m'a permis de lire ton message.
Mais bon sur le plan pratique je n'ai plus de problème puisque les clones de mon iMac que je fais maintenant son bootable. Cela m'a simplement obligé à faire une Clean Install un peu laborieuse.
M
Membre supprimé 1060554
Invité
Même si ton clone initial n'était pas démarrable par l'iMac > tu aurais pu faire une clean install sur l'iMac > et en fin d'installation agréer la demande : "voulez-vous récupérer les données d'un autre Mac" > en indiquant le volume monté du clone.
Le Système (démarrable) de l'iMac n'aurait pas été touché > mais les Applications > le compte d'utilisateur > et divers réglages de l'OS auraient été importés.
Si tu as toujours ton ancien Mac avec son volume > tu peux toujours refaire un tel clone > attacher le DDE à l'iMac > aller à : Applications > Utilitaires > Assistant de Migration > et dire que tu veux récupérer les données du volume du clone à l'iMac.
Après examen > des conflits seront notés, comme par exemple 2 comptes d'utilisateur du même nom --> tu n'aurais qu'à demander le remplacement du compte actuel par l'ancien.
=> ça > c'est pour le côté pratique. Pour le côté théorique (quel facteur exact empêche le clone de booter) > c'est l'échec des conjectures (en ce qui me concerne).
Le Système (démarrable) de l'iMac n'aurait pas été touché > mais les Applications > le compte d'utilisateur > et divers réglages de l'OS auraient été importés.
Si tu as toujours ton ancien Mac avec son volume > tu peux toujours refaire un tel clone > attacher le DDE à l'iMac > aller à : Applications > Utilitaires > Assistant de Migration > et dire que tu veux récupérer les données du volume du clone à l'iMac.
Après examen > des conflits seront notés, comme par exemple 2 comptes d'utilisateur du même nom --> tu n'aurais qu'à demander le remplacement du compte actuel par l'ancien.
=> ça > c'est pour le côté pratique. Pour le côté théorique (quel facteur exact empêche le clone de booter) > c'est l'échec des conjectures (en ce qui me concerne).
En tous cas merci de tes conseils et informations.
PS effectivement le forum a un bug au moment du changement de page
Dans mes souvenirs CCC demande si on veut créer une partition de récupération ou un truc comme ça.
(Je dit bien, dans mes souvenir, car cela fait un moment que je l'utilise, sur HDD et SSD.)
Avec pour choix : confirmer ou passer cette étape ( enfin je crois )
N'aurait-il pas " passer " cette étape ? ce qui bloquerait le boot .??????
(Je dit bien, dans mes souvenir, car cela fait un moment que je l'utilise, sur HDD et SSD.)
Avec pour choix : confirmer ou passer cette étape ( enfin je crois )
N'aurait-il pas " passer " cette étape ? ce qui bloquerait le boot .??????
Merci de ta réponse mais non j'accepte toujours cette implantation.
Non la raison est bien la différence de build entre la version de l'OS installé par apple sur les nouvelles machines et les OS dont nous disposons
J'avais ça qui m'était venu comme image, car il le demande qu'une fois lors du premier clone, et tu aurais pu ne pas t'en souvenir.
Et comme je l'avais déjà dit, j'avais cloner sur un Mac fraichement effacé en AS suite réparation, avec une Maj de retard !! mais bon.
Bah à suivre alors !!
Et comme je l'avais déjà dit, j'avais cloner sur un Mac fraichement effacé en AS suite réparation, avec une Maj de retard !! mais bon.
Bah à suivre alors !!
M
Membre supprimé 1060554
Invité
FULLCRUMJe profite de ton indication pour me « balader » un peu dans ce fil de manière spéculative. Parce que ton indication désigne un point tout à fait crucial : l'approche par «Carbon Copy Cloner» du problème de démarrage d'un volume cloné.
----------
Quand une partition de récupération Recovery HD existe sur le disque "source" > «Carbon Copy Cloner» propose par défaut de la cloner sur le disque de "destination", à la condition qu'elle ne soit pas déjà présente sur ce disque de destination. Cette possibilité est présentée, le cas échéant, une fois terminé le clonage principal de l'OS.
L'utilisateur a le choix d'accepter ou de refuser ce clonage de la Recovery HD sur un disque qui ne la comporte pas déjà. Que va-t-il se passer si l'utilisateur décline cette proposition de cloner la Recovery HD ?
Rien en ce qui concerne le caractère démarrable du clone > dès lors que le volume du clone est dans un format Apple_étendu journalisé (= JHFS+) standard. Car à la fin du clonage du volume de l'OS > le logiciel procède à la "bénédiction" (blessing) du volume du clone. C'est une commande qui assigne à l'en-tête de ce volume le flag (attribut) : "démarrable" et y inscrit le chemin au dossier recelant le fichier boot.efi (démarreur de l'OS cloné) : régulièrement --> /System/Library/CoreServices. En guise de couche de finition > «CCC» met à jour les caches de démarrage dans le système du clone.
Bref : le volume qui recèle le clone a tout ce qu'il faut pour être démarrable in fine - sans que la présence ou l'absence d'une Recovery HD joue le moindre rôle dans son démarrage.
Dans le cas de kinon
> la raison pour laquelle le clone de «Sierra» n'était pas démarrable par son iMac dernier cri provenait de ce que le build spécifique de cet OS cloné était identifié par l'EFI de son iMac comme incompatible.----------
Les choses se compliquent pour «Carbon Copy Cloner» lorsque l'OS "source" du clonage est supporté par un système de stockage dit : CoreStorage inscrit sur la partition principale du disque "source". Parce qu'un système de stockage CoreStorage nécessite un "déclencheur" : un « booter » de son dispositif logiciel. Ce « booter » réside dans une petite partition immédiatement subalterne à celle du CoreStorage.
Or cet emplacement immédiatement en-dessous de la partition CoreStorage est celui qui est assigné à la partition de secours Recovery HD. Il y a donc conflit d'emplacement pour deux fonctionnalités logiques : le déclenchement logiciel du CoreStorage par un « booter » et la présence d'un Système de secours démarrable Recovery OS.
Les ingénieurs de la ont résolu ce conflit en faisant "absorber" la fonctionnalité « booter » du CoreStorage par le volume montable Recovery HD. Ce volume recèle 2 dossiers : le dossier com.apple.recovery.boot qui contient le Système démarrable (optionnellement) du Recovery OS ; et le dossier com.apple.Boot.S qui contient le logiciel « booter » du système de stockage CoreStorage résident de la partition principale immédiatement supérieure sur le disque.
Cette solution clandestine fonctionne ainsi : le volume Recovery HD monté automatiquement au pré-boot sur la partition de secours sert principalement de « booter » du CoreStorage. C'est ce volume monté automatiquement au pré-boot qui, si l'on démarre avec "alt", s'affiche comme l'avatar du volume Macintosh HD de l'OS --> car le volume Macintosh HD porté par le CoreStorage n'est absolument pas monté à ce stade du pré-boot > seul le volume Recovery HD l'est dans sa fonction prioritaire de « booter » du CoreStorage.
Comme le volume monté de la Recovery HD l'est en tant que « booter » du Macintosh HD non monté supporté par le CoreStorage > il est impossible simultanément que ce volume Recovery HD soit affiché comme volume de la Récupération. C'est un cas classique d'exclusion logique de la contradiction des fonctions. Si donc le volume Recovery HD est monté en tant qu'assumant la fonction de « booter », il l'est alors sous l'intitulé du volume non monté qu'il permet de démarrer = « Macintosh HD » => il est alors impossible que ce même volume Recovery HD soit monté en tant qu'un « Récupération 10.x » permettant, à sa sélection, le démarrage sur le Recovery OS.
On tient là l'explication du fait que le Recovery OS (recelé dans le dossier com.apple.recovery.boot) se démarre par une commande directe au clavier ⌘R > puisque la fonction « booter » du CoreStorage prioritaire du volume Recovery HD l'empêche d'être monté comme volume indexant le système de récupération.
----------
Confronté à cette complexité spécifique du système de stockage CoreStorage > Mike Bombich (le développeur de «Carbon Copy Cloner») à jeté l'éponge : «CCC» ne clone pas le dispositif CoreStorage d'un disque "source" sur le disque "destination" > car cela impliquerait de générer ce format sur la partition d'accueil > ce qui créerait automatiquement une partition « booter » de type standard Boot OS X en-dessous. Cela fait > les fichiers de l'OS pourraient être clonés dans le volume monté sur le système de stockage CoreStorage > mais ensuite comment convertir la partition automatiquement créée du « booter » (la Boot OS X de 134 Mo) en une Recovery HD de 650 Mo conservant la fonction « booter » en mode principal > tout en étant implémentée de la fonction secondaire de Récupération ?
Donc «CCC» se borne à cloner le volume standard monté sur un CoreStorage, sans ce CoreStorage, dans un volume de destination standard ne nécessitant pas de « booter » --> ce qui lui permet de créer une « Recovery HD» classique uniquement dédiée à la fonction de récupération et n'ayant aucune fonction dans le démarrage du volume JHFS+ classique du clone.
----------
On peut donc considérer qu'il a reculé devant l'obstacle logiciel constitué par le type de démarrage auxiliaire d'un dispositif CoreStorage devant être inclus dans le volume Recovery HD.
...reculé pour mieux être condamné à sauter. Car il est rattrapé par l'évolution historique : le passage à l'APFS avec «High Sierra». Parce que l'APFS est un système de stockage héritier du CoreStorage (on pourrait dire que c'est l'avatar du CoreStorage incluant un nouveau système de fichiers).
L'APFS définit un Conteneur Logique à 4 Volumes : macOS > Preboot > Recovery > VM. Le Preboot est le volume « booter » du volume macOS > situé en-dessous de ce volume comme dans le CoreStorage sans qu'il s'agisse d'une partition de disque. Recovery est le volume de la récupération, distinct du Preboot => les ingénieurs de la ont décidé de ne plus combiner les fonctions dans un seul volume > mais de séparer les volumes dédiés aux fonctions « booter » et « récupération ». Le volume VM (Virtual Memory) contient une sleepimage image des contenus de la RAM.
Cloner un système de stockage APFS > c'est donc cloner un Conteneur Logique à 4 composants > le volume Preboot étant la condition absolument nécessaire du démarrage du volume macOS.
Or «Carbon Copy Cloner» jusqu'à présent s'est borné à un type de clonage en mode "fichiers" (en rejetant les procédés en mode "blocs logiques" comme asr ou dd) : se référer aux fichiers présentés en lecture dans un volume terminal par un système de fichiers > lire ces fichiers > et les injecter par copie dans un volume d'accueil standard. S'il ne veut pas se contenter de cloner les fichiers présentés dans un volume terminal par un système de fichiers APFS pour les injecter dans un volume à l'ancien standard JHFS+ > il faut donc que ce logiciel s'attaque à ce qu'il avait refusé d'assumer à l'époque du CoreStorage : le clonage de l'architecture de stockage dont le volume de l'OS n'est que le rejeton terminal. Système de stockage impliquant toujours un démarreur logique externe au volume cible (le « booter » CoreStorage devenant le Preboot APFS).
Il faut donc cloner une structure logicielle : cloner en mode "structuraliste" si je puis dire > et non plus cloner en mode élémentaire (une série de fichiers présentés en lecture sur le plateau d'un volume par un système de fichiers). L'exigence d'un travail d'ingéniérie énorme qui va sceller le destin des logiciels de clonage : ceux qui vont relever le défi et ceux qui vont jeter l'éponge.
Mais pourquoi??? Il suffira d'acheter la mise à jour compatible APFS!
(Je suppose qu'elle sera payante tant le travail de réécriture est important...)
