SuperDuper et Mojave, clone non bootable

[subsole]

Bonjour
J'utilise SuperDuper depuis longtemps pour faire mes clones, voici ma petite aventure :
- Je clone mon SSD interne High Sierra sur un SSD externe (ce clone de sauvegarde fonctionne parfaitement).
- Ensuite, j'installe Mojave sur un autre SSD externe pour tester puis je migre mon User, après test aucun problème.
Je décide d'effacer mon SSD interne pour y cloner Mojave+User qui se trouve sur un SSD externe, surprise au redémarrage l'iMac ne voit pas le système, j'ai un magnifique dossier avec un ?:bored:
Le SSD est non bootable, je décide de reformater (APFS) mon SSD interne, et de tenter à nouveau le clonage de Mojave depuis le SSD externe sur l'interne, résultat même punition le SSD interne est non bootable mais contient Mojave+User.:meh:
Pour m'en sortir j'ai "simplement" réinstallé Mojave sur le SSD interne (depuis l'installateur qui se trouvait sur le SSD externe), mais que de temps perdu !:banghead:

Conclusion, ici SuperDuper 3.2.2 semble avoir des problèmes, fézégafff.

PS
Avez vous testé cette version de SuperDuper, si oui, avez vous le même problème ?
Avez vous testé CCC comment se comporte t il ?

PS2
Cerise sur le gâteau, J'ai obligé de reparamètrer Apache & PHP c'est SuperDuper:siffle:

 

[r e m y]

Quel modèle de Mac utilises-tu?
Si c'est un Mac récent avec puce de sécurité T2, avec Mojave il faut impérativement autoriser le démarrage sur un disque externe.
C'est peut-être ça ton problème pour booter sur le clone sur SSD externe.

(Même souci potentiel pour booter sur une clé usb d'installation de macOS si le boot sur disque externe n'a pas été autorisé dans les options de sécurité de Mojave)

 

[subsole]

Bonjour r e m y
Ici, j'utilise un iMac 5K 27 fin 2014.

 

[r e m y]

Donc le problème est ailleurs...

 

[subsole]

Effectivement, pas de T2.
En plus j'avais testé Mojave(+User migré) depuis un SSD externe sans problème de boot.

 

[subsole]

Personne ne semble cloner Mojave sur MacG

 

[r e m y]

J'utilise CCC... désolé

 

[subsole]

J'ai fait des PS que u n'as pas du voir
CCC fonctionne bien dans la configuration décrite dans mon premier poste ?

 

[Locke]

Personne ne semble cloner Mojave sur MacG

J'utilise bien SuperDuper! et étant curieux, j'ai donc fait une restauration d'un clone et pas de problème. Et là je suis sûr que ça fonctionne étant donné que mon clone n'était pas à jour sous macOS Mojave 10.14.1. J'ai le sentiment que cela provient d'Utilitaire de disque, mais je ne saurais pas l'expliquer, car j'avais rencontré une situation similaire et j'avais donc formaté mon disque dur USB via le Terminal.

Avant d'aller plus loin, j'ai donc vérifié plusieurs fois que ce clone était bien bootable avant de tenter de faire une restauration.

 

[subsole]

Je précise que le clone que je tentais de faire, était depuis un Mojave 10.14 sur SSD (CrucialMX500) externe vers le SSD interne de l'iMac, avec SuperDuper 3.2.2 installé sur le SSD externe.
J'ai tenté l'opération deux fois, la seconde fois j'ai même reformaté le SSD de l'iMac avant transfère, résultat non bootable les deux fois.:bored:

 

[Locke]

C'est bien ce que j'ai fait aussi, j'ai quand même l'impression qu'il y a en effet un problème avec le boot de démarrage. Par curiosité, lorsque tu avais ce problème, en démarrant tout en maintenant la touche alt, est-ce que tu pouvais quand même démarrer et avoir accès au Bureau ?

Sinon, il faudrait que macomaniac décortique le pourquoi du comment.

 

[Locke]

Allez je reviens pour mentionner qu'il y a bien un petit problème, mais je ne sais pas pourquoi pour le moment. Mon clone est bien bootable, donc pas de souci j'ai bien démarré dessus. Pour être sûr que tout soit bien restauré sans scories d'anciens fichiers, j'ai donc effacé mon disque dur interne via Utilitaire de disque. Ensuite j'ai lancé la restauration qui passe sans problème, premier démarrage tout est normal, je déconnecte mon clone USB, puis j'éteins mon iMac.

Après une minute, je rallume mon iMac et oh surprise, le fameux dossier avec le point d'interrogation ! Je persiste et signe en faisant une seconde restauration et toujours pas de problème, rien d'anormal dans les partitions via le Terminal. Je redémarre et re-bingo, une seconde fois le dossier avec le point d'interrogation est encore là !

C'est déconcertant, mais je redémarre tout en maintenant la touche alt et oh miracle Macintosh HD est bien présent et démarre normalement. La curiosité me pique, je vais dans Préférences Système/Disque de démarrage et là Macintosh HD est grisé, je le sélectionne, redémarre et aucun problème. J'éteins de nouveau mon iMac et le rallume, pas de problème.

Toujours intrigué, je recommence à effacer le disque dur interne, troisième restauration et tout recommence comme au début, le dossier avec le point d'interrogation, mais redémarre normalement avec le maintien de la touche alt, même chose en allant dans Préférences Système/Disque de démarrage, je dois le sélectionner pour que celui-ci soit bien reconnu au démarrage. Ce bug provient de SuperDuper! ou de Mojave ?

 

[subsole]

Dans les deux cas en maintenant alt au démarrage je n'avais pas le choix du SSD interne, je voyais uniquement les partions bootable des SSD externes.
Ou en démarrant (après avoir débrancher les SSD externes), je tombais sur le dossier+? .
Une fois le problème ""résolut par la réinstallation par dessus"" de Mojave à partir de l'installeur, le SSD interne est devenu bootable et les Users fonctionnels.
Il doit y avoir des problème de droits :
- J'utilise deux Users en admin.
- J'ai une archive sécurisée sur la l'User2admin (archive créée par ce mêmeUser2) mais je ne pouvais l'ouvrir : "MDP invalide".:meh:
En fait, elle réclamait les droits admin de l'User1admin :bored:

 

[Locke]

@subsole
Je reviens encore une fois de plus, bon je n'ai pas de solution, mais ce problème existe bien. J'ai donc recommencé, effacement de mon disque dur interne, redémarrage pour confirmer que le disque dur interne est bien vide. Lancement de mon clone, pas de problème, lancement de SuperDuper! qui fait la restauration sans broncher. Mais là, j'éteints et j'attends 5 minutes, histoire que mon iMac ait vidé tout ce qui est non volatile dans les barrettes mémoires.

Démarrage et pas de miracle, je me retrouve avec le dossier avec le point d'exclamation. Redémarrage depuis le clone, puis dans Préférences Système/Disque de démarrage je sélectionne Macintosh HD qui est bien présent, nouveau redémarrage et tout est rentré dans l'ordre ! Pourquoi ce bug ? Bien entendu je ne sais pas et dans les forums de SuperDuper!, il n'y a pas d'informations.

 

[Membre supprimé 1060554]

Je salue les 3 participants de ce fil : subsole, r e m y, Locke

Sinon, il faudrait que macomaniac décortique le pourquoi du comment.

• si je me référe à ces 2 descriptions -->

Je recommence à effacer le disque dur interne, troisième restauration et tout recommence comme au début, le dossier avec le point d'interrogation, mais redémarre normalement avec le maintien de la touche alt, même chose en allant dans Préférences Système/Disque de démarrage, je dois le sélectionner pour que celui-ci soit bien reconnu au démarrage. Ce bug provient de SuperDuper! ou de Mojave ?

Lancement de mon clone, pas de problème, lancement de SuperDuper! qui fait la restauration sans broncher. Mais là, j'éteints et j'attends 5 minutes, histoire que mon iMac ait vidé tout ce qui est non volatile dans les barrettes mémoires.

Démarrage et pas de miracle, je me retrouve avec le dossier avec le point d'exclamation. Redémarrage depuis le clone, puis dans Préférences Système/Disque de démarrage je sélectionne Macintosh HD qui est bien présent, nouveau redémarrage et tout est rentré dans l'ordre ! Pourquoi ce bug ?

• j'ai l'impression que le scénario est le suivant : a) démarrage sur un clone externe de Mojave (en format apfs) > b) effacement du disque interne avec recréation d'un format apfs > c) rétro-clonage avec Super Duper! au volume interne > d) redémarrage automatique (sans option au clavier) => dossier clignotant avec un ? équivalant à : volume démarrable non trouvé > e) démarrage alternatif avec "alt" => volume interne cloné Macintosh HD = affiché > choisissable > démarrable > f) (alternative à e) : démarrage sur le Clone > Disque de démarrage > choix de Macintosh HD affiché > redémarrage automatique réussi sur Macintosh HD

Est-ce que je me trompe ?

Si je n'erre pas > je voudrai esquisser un commentaire dans ce qui suit. La limitation des 5000 caractères m'oblige à répartir mon topo en plusieurs segments. J'avais l'intention initiale de me montrer concis et sommaire > et puis... comme souvent > je m'avise que la concision est obscure et que la précision implique de développer l'analyse. Ce qui illustre la déclaration (apparemment) paradoxale de Kant : « Bien des écrits seraient beaucoup plus courts, s'ils n'étaient pas si courts ». Ce qui veut dire : exposer quelque chose dans le détail (long à lire) permet une compréhension suffisante (court à entendre). Alors que l'inverse : exposer quelque chose de manière sommaire (court à lire) > laisse l'esprit en plein problème de compréhension (long à entendre).

 

[Membre supprimé 1060554]

2 facteurs entrent en jeu dans le boot volontaire d'un volume macOS -->

- a) un facteur propre au volume = un chemin de démarrage > pointant au lanceur boot.efi de l'OS installé. Le lanceur boot.efi une fois activé > prend en charge un cache-Système prelinkedkernel qui contient : un clone du code du kernel + un tableau d'adresses de kexts ou extensions. Le lanceur boot.efi charge le kernel du cache en RAM > lui transmet d'éventuelles instructions reçues de l'EFI (comme les flags du SIP) > puis lui injecte les extensions. Cela fait > le boot.efi quitte en tant qu'application > et c'est le kernel démarré en RAM qui constitue désormais le moteur logique autonome dont tout va s'ensuivre.

• dans les volumes de démarrage de format jhfs+ (volumes OS X + Sierra 10.12) > le chemin de démarrage est inscrit sur l'en-tête de ce même volume. Il s'agit d'une adresse logique de type : /System/Library/CoreServices/boot.efi. Dans les volumes de démarrage de format apfs (High Sierra 10.13 & Mojave 10.14) > le chemin de démarrage n'est plus supporté par l'en-tête du volume de démarrage apfs > mais stocké dans le volume auxiliaire Preboot. Il s'agit alors d'une adresse logique rallongée : /Volumes/UUID_Macintosh HD/System/Library/CoreServices/boot.efi.

Le fait qu'à un volume contenant un OS possède d'un chemin de démarrage (blessing ou bénédiction) soit intrinsèque (format jhfs+) soit extrinsèque (format apfs) --> permet au boot_manager (gestionnaire de démarrage) = sous-programme de boot de l'EFI appelé par la touche "alt" --> lors du scan des volumes montés (tous les volumes existants sont montés dans le temps du boot) --> de détecter Macintosh HD comme nanti d'un chemin de démarrage valide à un boot.efi => ce qui fait que le volume est alors affiché à l'écran de choix du volume de démarrage.

 

[Membre supprimé 1060554]

- b) un facteur propre à la NVRAM. Quand l'utilisateur sélectionne le volume affiché à l'écran du boot_manager et valide > cet acte inscrit dans la mémoire NVRAM un chemin de démarrage provisoire (à une variable impermanente créée uniquement pour l'occasion : efi-boot-device-next-only) mentionnant l'adresse au volume choisi.Puis l'EFI (programme interne de boot du Mac) qui était en stand-by d'opération > se trouve "libérée" : ce programme visite alors la NVRAM > et lit le chemin de démarrage efi-boot-device-next-only qui mène au volume-cible : soit le volume jhfs+ > soit le Preboot apfs. Là > il y a relais d'adresse par le chemin de démarrage > soit de l'en-tête du volume jhfs+ > soit du volume apfs Preboot. L'EFI accède donc en bout de chemins au boot.efi et l'exécute en tant qu'application primaire de l'EFI avant de quitter.

Si j'ai bien interprété le scénario de Locke --> alors le clone créé par Super Duper ! dans le volume interne apfs > se trouve toujours démarrable avec "alt". C'est la preuve que le cloneur > en fin de copie du clone dans le volume de destination > a bien effectué un blessing du volume de destination = une adresse de démarrage valide se trouve stockée dans le volume de prédémarrage Preboot = /Volumes/UUID_Macintosh HD/System/Library/CoreServices/boot.efi. Le choix de Macintosh HD à l'écran du boot_manager --> crée une variable impermanente en NVRAM = efi-boot-device-next-only portant le chemin au volume-cible > libère l'EFI > qui n'a plus qu'a suivre le double chemin : de la NVRAM = /Volumes/Preboot => du Preboot = /Volumes/UUID_Macintosh HD/System/Library/CoreServices/boot.efi. Au bout de ce chemin double --> le boot.efi est trouvé et le lancement s'effectue.

=> conclusion : Super Duper! se montre irréprochable en tant que cloneur > en ayant effectué la copie + le blessing.

 

[Membre supprimé 1060554]

J'ai tenté de décrire ce qui permet le démarrage du volume Macintosh HD par choix volontaire d'utilisateur (alt). Voici à présent le 2è cas de figure : un démarrage automatique du Mac sur le volume Macintosh HD. Qu'est-ce qui permet ce démarrage automatique ?

Une combinaison de 2 facteurs encore : chemin du volume + chemin de NVRAM. Le chemin du volume est exactement le même que dans le cas précédent : pour un volume APFS = /Volumes/UUID_Macintosh HD/System/Library/CoreServices/boot.efi stocké dans Preboot. Mais le chemin en NVRAM est différent : il ne s'agit plus d'une variable efi-boot-device-next-only inscrite en NVRAM par une sélection volontaire à l'écran du boot_manager (variable impermanente car elle est purgée de la NVRAM après service : elle ne vaut "que pour la fois prochaine"). Il s'agit d'une variable permanente intitulée : efi-boot-device (appareil de démarrage automatique de l'EFI).

Lorsqu'un utilisateur se sert du panneau Disque de démarrage des Préférences Système pour sélectionner Macintosh HD puis referme le panneau --> cette action induit un acte d'écriture sur la NVRAM qui est : l'inscription d'un chemin permanent au volume cible à la variable efi-boot-device. Une fois cette inscription faite > démarrer automatiquement le Mac (sans option au clavier) déclenche l'EFI qui visite la NVRAM > lit le chemin à la variable efi-boot-device > va au volume Preboot mentionné > et là lit le chemin de démarrage stocké : /Volumes/UUID_Macintosh HD/System/Library/CoreServices/boot.efi. Ce qui fait que Macintosh HD démarre.

Si l'utilisateur choisit à un moment donné de démarrer avec "alt" --> en parallèle de la variable permanente efi-boot-device > s'incrit une variable impermanente : efi-boot-device-next-only qui a toujours la préséance (over-riding) pour l'EFI sur efi-boot-device si elle existe. Le Mac démarrera sur le volume choisi volontairement > puis la variable impermanente efi-boot-device-next-only sera purgée de la NVRAM et ne restera que la variable permanente efi-boot-device. Au prochain démarrage automatique > l'EFI suivra le chemin de l'efi-boot-device > ira au Preboot > suivra le chemin de démarrage de Macintosh HD et exécutera le boot.efi.

 

[Membre supprimé 1060554]

Mais que se passe-t-il si l'utilisateur réinitialise son disque interne avant de cloner ? --> il crée un nouveau Conteneur apfs avec un volume Macintosh HD défini par un autre UUID que le volume antérieur. Le cloneur Super Duper! va donc rétro-cloner intégralement à ce nouveau volume > puis créer en fin de clonage les volumes auxiliaires > dont un Preboot défini par un autre UUID de volume apfs auxiliaire que le Preboot antérieur. Ce nouveau volume Preboot est alors mis à jour du chemin de démarrage du nouveau Macintosh HD > càd. portant un chemin /Volumes/UUID_Macintosh HD/System/Library/CoreServices/boot.efi dans lequel l'UUID de Macintosh HD a été mis à jour de l'UUID du nouveau volume créé.

Mais que se passe-t-il alors en NVRAM ? --> eh bien ! la variable permanente efi-boot-device n'a pas changé de définition : le chemin de démarrage automatique pour l'EFI mentionne toujours /Volumes/UUID de l'ancien Preboot. En suivant ce chemin > l'EFI ne trouve aucun volume > puisque le nouveau Preboot est défini par un autre UUID. Il en va de même si le volume de démarrage est de format jhfs+ classique. Le reformatage de Macintosh HD a créé un volume de nouvel UUID > autre que l'UUID de volume stocké à la variable efi-boot-device de la NVRAM.

 

[Membre supprimé 1060554]

En résumé : le boot automatique du Mac suppose le relais de 2 chemins bout-à-bout : le chemin efi-boot-device en NVRAM au volume Preboot (apfs) ou Macintosh HD (jhfs+) > le chemin de démarrage au lanceur boot.efi soit stocké dans Preboot (apfs) > soit sur l'en-tête de Macintosh HD (jhfs+). Tant qu'un rétroclonage s'effectue sans aucune réinitialisation du disque interne ou reformatage du volume interne > les UUID de volumes sont constants --> l'UUID de volume cible mentionné en NVRAM à l'efi-boot-device conserve une validité permanente. Après clonage > le Mac boote automatiquement sur Macintosh HD. Par contre > tout acte de réinitialisation du disque interne ou de reformatage du volume classique --> change les UUID de volumes internes. En cas d'apfs > le nouveau volume Preboot n'a pas le même UUID que celui de l'ancien Preboot conservé en NVRAM à l'efi-boot-device. Démarrer automatiquement dans ces conditions ... plante car l'EFI ne trouve pas le nouveau Preboot faute du bon UUID.

On ne peut absolument pas incriminer un cloneur comme Super Duper! de ne pas mettre à jour l'adresse de l'efi-boot-device en NVRAM. Car ! --> ce ne doit absolument pas faire partie des prérogatives d'un cloneur ! --> un cloneur doit mettre à jour le chemin de démarrage intrinsèque du volume de destination (blessing) --> il ne doit absolument pas intervenir sur la NVRAM. Ce que les cloneurs respectent. Seul, le programme d'installation de macOS effectue par défaut la double opération en fin d'installation : bénédiction de Macintosh HD par stockage d'un chemin valide au boot.efi dans Preboot + mise-à-jour de l'efi-boot-device en NVRAM par inscription de l'UUID du nouveau Preboot.