10.13 High Sierra Problème démarrage macbook pro 2011
- Créateur du sujet Makeur
- Date de début
M
Membre supprimé 1060554
Invité
Clone est parfaitement monté et la mesure de son occupation en blocs est 664 Mo (on dira : la taille du système de fichiers reportée en occupation minimale du volume vide qu'il détermine)
Alors on peut cloner directement de volume à volume. Passe la commande :
=> si tu vois commencer de défiler rapidement une forêt de lignes --> c'est potentiellement gagné : c'est que le clonage à commencé. Est-ce que c'est bien le cas ?
Alors on peut cloner directement de volume à volume. Passe la commande :
Bloc de code:
sudo rsync -avx /* /Volumes/Clone- et que tu tapes ainsi :
Bloc de code:
sudo rsync )qvx =⇧! =Volu,es=Clone- l'astérique * se tape sur un QWERTY par la combinaison de touches : maj 8 --> d'où mon ⇧ (pour maj) et mon ! (puisque le chiffre 8 se frappe directement). Respecte tous les espaces
- la commande lance le clonage intégral du volume de démarrage Mac SSD dans le volume Clone. L'option x interdit à la commande de descendre dans le répertoire /Volumes quand elle y arrivera > pour ne pas qu'elle prenne pour objets sources de copie des éléments relevant d'un UUID de volume différent de celui du volume source Mac SSD. Ce qui empêche qu'elle se mette à copier dans Clone les contenus du même volume Clone trouvé monté dans /Volumes --> boucle infinie.
- la commande affiche une ligne par fichier copié. Elle suit l'ordre alphabétique des dossiers > sous-dossiers > fichiers. rsync commence toujours par construire une liste de copie > avant de déclencher l'exécution de la copie --> tu devrais donc voir afficher un :
Bloc de code:
building file list ...- pendant plusieurs minutes > conclu par un :
Bloc de code:
done=> si tu vois commencer de défiler rapidement une forêt de lignes --> c'est potentiellement gagné : c'est que le clonage à commencé. Est-ce que c'est bien le cas ?
M
Membre supprimé 1060554
Invité
@ Makeur
Tant que tu ne vois pas défiler de lignes --> c'est que l'activité de copie n'est pas lancée en elle-même.
D'après des tests que j'avais faits --> le Mac ne se met jamais en veille en Single User pendant un clonage : tu peux laisser faire. La complétion de la copie s'indiquera simplement par l'arrêt du défilé et le réaffichage de l'invite de commande root#.
Si tu guignes le coin supérieur gauche de l'écran > tu pourras voir quel est le dossier du volume source en train d'être copié > genre :
----------
@ bompi
Je sais bien que sudo a l'air redondant dans un Terminal root. Mais en Single User : les choses sont bizarres du collier. D'après certains de mes tests antérieurs > il faut sudo pour lancer diskutil > sinon ça plante. J'ai donc extrapolé ici à ma commande de copie.
Tant que tu ne vois pas défiler de lignes --> c'est que l'activité de copie n'est pas lancée en elle-même.
D'après des tests que j'avais faits --> le Mac ne se met jamais en veille en Single User pendant un clonage : tu peux laisser faire. La complétion de la copie s'indiquera simplement par l'arrêt du défilé et le réaffichage de l'invite de commande root#.
Si tu guignes le coin supérieur gauche de l'écran > tu pourras voir quel est le dossier du volume source en train d'être copié > genre :
Bloc de code:
/Applications/---
/Library/---- le gros des données devant résider dans :
Bloc de code:
/Users/tonnom/-------------
@ bompi
Je sais bien que sudo a l'air redondant dans un Terminal root. Mais en Single User : les choses sont bizarres du collier. D'après certains de mes tests antérieurs > il faut sudo pour lancer diskutil > sinon ça plante. J'ai donc extrapolé ici à ma commande de copie.
Là, tu m'intrigues.
On n'est jamais à l'abri d'une spécificité d'Apple mais en mono-utilisateur, on est de fait quelque chose comme l'utilisateur root (pour que le système fonctionne, il en faut un et s'il ne doit y en avoir qu'un, c'est lui).
Quand j'ai testé ton tuto sur mon MBP hors d'âge, je n'ai pas mis de sudo et j'ai pu tout lancer comme attendu. Le résultat n'a pas été concluant mais c'est sans doute que j'ai dû désactiver trop de services par ailleurs.
J'arrête là mon HS.
Difficile de dire avec certitude quels fichiers ont pu être problématiques, puisqu'on ne le voit pas à l'écran.
Mais ce n'est sans doute pas bien grave : de telles erreurs de transfert peuvent être imputées aux fichiers spéciaux qui se trouvent dans /dev et quelques autres lieux [il faudrait éviter de les copier parce qu'ils ne doivent pas l'être].
[Si on voulait récupérer les erreurs de copie et donc s'assurer que rien d'important n'a été perdu, il faudrait ajouter quelque chose en fin de commande :
Cela permet de récupérer les sorties (tout, ne lésinons pas) dans le fichier /tmp/rsync.log pour une éventuelle analyse de la copie.]
L'écart de taille entre la source (177 GiB) et la destination (181 GiB) n'est pas significatif et on peut penser que toutes les données sont bel et bien là.
Inspecte un peu ce qui t'intéresse et une fois que tu es satisfait, tu peux passer à la suite.
Mais ce n'est sans doute pas bien grave : de telles erreurs de transfert peuvent être imputées aux fichiers spéciaux qui se trouvent dans /dev et quelques autres lieux [il faudrait éviter de les copier parce qu'ils ne doivent pas l'être].
[Si on voulait récupérer les erreurs de copie et donc s'assurer que rien d'important n'a été perdu, il faudrait ajouter quelque chose en fin de commande :
Bloc de code:
rsync -avx /* /Volumes/Clone >/tmp/rsync.log 2>&1L'écart de taille entre la source (177 GiB) et la destination (181 GiB) n'est pas significatif et on peut penser que toutes les données sont bel et bien là.
Inspecte un peu ce qui t'intéresse et une fois que tu es satisfait, tu peux passer à la suite.
M
Membre supprimé 1060554
Invité
MakeurLe message d'erreur me paraît marginal.
Tu as repassé la commande df avec l'option -h (en minuscule) qui donne une mesure en Gi (gibibytes : base 2). C'est l'option -H (avec une majuscule) qui donne une mesure en Go (gigabytes : base 10). Ça ne fait rien : je donne les conversions -->
- Mac SSD : 177 Gi = 190 Go de contenu vs Clone : 181 Gi = 194 Go de contenu
Quelques Go en plus sur la destination sont réguliers avec des cloneurs comme cp ou rsync dans des circonstances où la source est un volume monté en lecture seule à cause de la corruption du système de fichiers. Pas trop (j'ai vu passer des cas où il y avait jusqu'à 100 Go en plus !) - ce qui serait problématique > et pas moins (ce qui signale des input/output errors d'accès).
J'estime que ton clone est un bon clone (quantitativement parlant).
Si tu voulais > je peux te proposer des commandes mesurant (en Gi) les dossiers de 1er rang des 2 volumes --> pour effectuer un comparatif plus détaillé.
----------
Passe les commandes :
Bloc de code:
sudo kextcache -u /Volumes/Clone
sudo bless --folder /Volumes/Clone/System/Library/CoreServices --file /Volumes/Clone/System/Library/CoreServices/boot.efi- la 1ère met à jour le cache prelinkedkernel > chargé par le lanceur boot.efi au démarrage ; elle passe sans commentaire
- la 2è inscrit un chemin de démarrage sur l'en-tête du volume Clone > pointant au lanceur boot.efi de l'OS cloné ; elle passe sans commentaire
=> tu auras compris que ces 2 commandes tentent de rendre le volume Clone démarrable par l'EFI et son Système chargeable par le lanceur. Cela fait > passe la commande informative :
Bloc de code:
bless --info /Volumes/Clone- qui affiche le chemin de démarrage actif du volume
Poste le tableau retourné.
Visiblement, la seconde commande s'est bien déroulée et le DDE est devenu potentiellement démarrable.
Mais la première, avec ses warnings et son erreur 107 est intrigante.
Quand on lit la documentation de kextcache on se dit que cela pourrait avoir marché ("If kextcache cannot find or make sense of os_volume/usr/standalone/bootcaches.plist the volume is treated as if no caches need updating: success is returned") mais le message est ambigu (on devrait avoir un chemin démarrant sur /Volumes/Clone).
Pour s'assurer du résultat, pourrais-tu repasser cette commande ?
Puis immédiatement après, celle-ci :
Elle renvoie le code de sortie de la commande précédente : si c'est 0 (zéro) c'est que ça s'est bien passé. Sinon il y a eu une erreur.
Quoi qu'il en soit, tu peux toujours essayer de démarrer puisque le disque est supposément démarrable (appuyer sur alt au démarrage puis le choisir).
Mais la première, avec ses warnings et son erreur 107 est intrigante.
Quand on lit la documentation de kextcache on se dit que cela pourrait avoir marché ("If kextcache cannot find or make sense of os_volume/usr/standalone/bootcaches.plist the volume is treated as if no caches need updating: success is returned") mais le message est ambigu (on devrait avoir un chemin démarrant sur /Volumes/Clone).
Pour s'assurer du résultat, pourrais-tu repasser cette commande ?
Puis immédiatement après, celle-ci :
Bloc de code:
echo $?Quoi qu'il en soit, tu peux toujours essayer de démarrer puisque le disque est supposément démarrable (appuyer sur alt au démarrage puis le choisir).
M
Membre supprimé 1060554
Invité
La commande kextcache de mise à jour du cache de démarrage prelinkedkernel --> inscrit dans le cache un clone du code du kernel (que le lanceur boot.efi pourra charger en RAM) > et le bloc d'adresses des kexts (extensions du noyau ou pilotes) que le même lanceur boot.efi pourra injecter dans le kernel "en paquet" (sans vérification terme à terme).
En plus des commandes d'initalisation de services de mon tuto > il faudrait donc ajouter la commande :
----------
La commande bless d'inscription d'un chemin de démarrage a fonctionné elle : le chemin affiché par la commande d'information ensuite est valide. La preuve --> lorsque tu as redémarré (avec la touche "alt" je présume) --> le volume Clone était affiché comme démarrable à l'écran du gestionnaire de démarrage (= boot_manager de l'EFI) > l'EFI a pu suivre le chemin d'accès pour exécuter le lanceur boot.efi.
L'affichage d'une à l'écran de démarrage --> signale que le boot_loader : boot.efi a bien été exécuté par l'EFI > et qu'il a procédé avec succès au chargement du kernel en RAM et à l'injection des extensions. Cet affichage que tu as obtenu --> m'invite à penser que la mise-à-jour du cache prelinkedkernel via une initialisation du service kextd est donc dispensable.
[je reporte la suite de mon laïus à un second message - pour éviter la limites des 5000 caractères pour un message.]
----------
- cette commande échoue parce que le service kextd (kext_daemon) n'est pas initialisé. Il s'agit d'un service qui surveille en permanence les "sources" & les "destinations" (si je puis dire) en ce qui concerne les extensions du noyau. Non seulement le répertoire /System/Library/Extensions du volume démarré > mais tous les répertoires de type System/Library/Extensions présents dans tout volume monté (cet ennuyeux service kextd est fréquemment responsable d'une impossibilité de démonter dans un temps réglementaire un volume externe qui recèle un système > parce qu'il "occupe" ce volume par sa tâche de surveillance du dossier Extensions) = "sources". Mais aussi le cache /System/Library/PrelinkedKernels/prelinkedkernel (aussi bien dans le volume démarré que dans des volumes externes non démarrés) = "destinations".
En plus des commandes d'initalisation de services de mon tuto > il faudrait donc ajouter la commande :
Bloc de code:
launchctl load /System/Library/LaunchDaemons/com.apple.kextd*- afin d'activer le service kextd et permettre par là la mise à jour du cache prelinkedkernel
----------
La commande bless d'inscription d'un chemin de démarrage a fonctionné elle : le chemin affiché par la commande d'information ensuite est valide. La preuve --> lorsque tu as redémarré (avec la touche "alt" je présume) --> le volume Clone était affiché comme démarrable à l'écran du gestionnaire de démarrage (= boot_manager de l'EFI) > l'EFI a pu suivre le chemin d'accès pour exécuter le lanceur boot.efi.
L'affichage d'une à l'écran de démarrage --> signale que le boot_loader : boot.efi a bien été exécuté par l'EFI > et qu'il a procédé avec succès au chargement du kernel en RAM et à l'injection des extensions. Cet affichage que tu as obtenu --> m'invite à penser que la mise-à-jour du cache prelinkedkernel via une initialisation du service kextd est donc dispensable.
[je reporte la suite de mon laïus à un second message - pour éviter la limites des 5000 caractères pour un message.]
----------
Dernière édition par un modérateur:
M
Membre supprimé 1060554
Invité
L'affichage de la barre horizontale signale l'engagement du processus du noyau en RAM (kernel_task). Processus qui se décompose en 2 actes de longueur inégale : le processus dit : "intra_kernel" de prise en charge du Système BSD > puis le processus dit : "extra_kernel" d'INITialisation de l'OS (services etc.) par le processus parent launchd. La progression d'une jauge dans la barre de chargement signale grosso mode l'effectuation de ces 2 processus.
Lorsque la jauge ratatouille passé (disons) plusieurs centimètres à partir du début > c'est qu'après la prise en charge du Système BSD --> le processus launchd est en pleine déroute (dès le lancement ou en cours d'opération).
Dans ton cas --> j'avise une jauge pleine (barre de chargement remplie jusqu'au bout). Il est d'une importance décisive que tu dises si la jauge a rempli complètement la barre horizontale de chargement > avec un ralentissement d'avancée dramatique sur (disons) toute la seconde moitié.
Si tel était bien le cas --> alors la raison du plantage de démarrage de ton volume Mac SSD serait connue --> facteur de plantage qui se serait itéré dans le volume Clone lors du clonage par rsync.
En effet --> un bogue spécifique à l'OS High Sierra induit la corruption du cache de l'Open Directory (Service d'Annaire qui gère les utilisateurs & les groupes). Cache situé dans le volume de démarrage at: /private/var/db/caches/opendirectory/mbr_cache. La corruption de ce cache détermine pendant le travail de launchd un "effet de boucle" signalé en mode verbose comme : "too many corpses being created". La conséquence en est constamment le blocage du processus LoginWindow d'affichage d'un écran de connexion permettant à l'utilisateur d'ouvrir sa session.
Dans des dizaines de cas sur les forums MacGé --> j'ai pu passer à des demandeurs d'aide une commande de suppression du cache corrompu qui a libéré l'ouverture de session. On peut donc miser sur l'option ténue que > dans ton cas > la suppression du cache mbr_cache dans le volume Clone --> permettrait son démarrage jusqu'à l'ouverture de session. Suppression du cache mbr_cache impossible en 1ère instance dans le volume Mac SSD > puisqu'il est monté par défaut en lecture seule dans la session du Single User. Mais rien ne dit que Mac SSD ne soit pas remontable en lecture & écriture > afin que tu puisses supprimer également le cache mbr_cache dont la corruption serait le facteur de plantage de son démarrage. Ce qu'on appelle faire coup double.
Passe les commandes :
=> tu n'as plus qu'à tester (via "alt") les 2 démarrages : sur Clone vs Mac SSD.
Lorsque la jauge ratatouille passé (disons) plusieurs centimètres à partir du début > c'est qu'après la prise en charge du Système BSD --> le processus launchd est en pleine déroute (dès le lancement ou en cours d'opération).
Dans ton cas --> j'avise une jauge pleine (barre de chargement remplie jusqu'au bout). Il est d'une importance décisive que tu dises si la jauge a rempli complètement la barre horizontale de chargement > avec un ralentissement d'avancée dramatique sur (disons) toute la seconde moitié.
Si tel était bien le cas --> alors la raison du plantage de démarrage de ton volume Mac SSD serait connue --> facteur de plantage qui se serait itéré dans le volume Clone lors du clonage par rsync.
En effet --> un bogue spécifique à l'OS High Sierra induit la corruption du cache de l'Open Directory (Service d'Annaire qui gère les utilisateurs & les groupes). Cache situé dans le volume de démarrage at: /private/var/db/caches/opendirectory/mbr_cache. La corruption de ce cache détermine pendant le travail de launchd un "effet de boucle" signalé en mode verbose comme : "too many corpses being created". La conséquence en est constamment le blocage du processus LoginWindow d'affichage d'un écran de connexion permettant à l'utilisateur d'ouvrir sa session.
Dans des dizaines de cas sur les forums MacGé --> j'ai pu passer à des demandeurs d'aide une commande de suppression du cache corrompu qui a libéré l'ouverture de session. On peut donc miser sur l'option ténue que > dans ton cas > la suppression du cache mbr_cache dans le volume Clone --> permettrait son démarrage jusqu'à l'ouverture de session. Suppression du cache mbr_cache impossible en 1ère instance dans le volume Mac SSD > puisqu'il est monté par défaut en lecture seule dans la session du Single User. Mais rien ne dit que Mac SSD ne soit pas remontable en lecture & écriture > afin que tu puisses supprimer également le cache mbr_cache dont la corruption serait le facteur de plantage de son démarrage. Ce qu'on appelle faire coup double.
Passe les commandes :
Bloc de code:
sudo rm -f /Volumes/Clone/var/db/caches/opendirectory/*
mount -uw /
sudo rm -f /var/db/caches/opendirectory/*- la 1ère supprime le cache mbr_cache dans Clone
- la 2è remonte en lecture & écriture le volume Mac SSD pré-monté en lecture seule
- la 3è supprime le cache mbr_cache dans Mac SSD
=> tu n'as plus qu'à tester (via "alt") les 2 démarrages : sur Clone vs Mac SSD.
Dernière édition par un modérateur:
Salut macomaniac ,
Lorsque j'ai démarré sur le disque dur externe, la première moitié de la jauge est allé rapidement et la deuxième jauge à eu besoin de 10min pour se remplir.
J'ai passé les commandes que tu m'as dit mais impossible d'accéder à la page login que ce soit sur le disque dur externe ou Mac sud
Pour information, j'ai redémarre le mac et je suis passé en single user . J'ai passé les commandes que tu m'as dit et j'ai tapé reboot puis alt au démarrage.
Lorsque j'ai démarré sur le disque dur externe, la première moitié de la jauge est allé rapidement et la deuxième jauge à eu besoin de 10min pour se remplir.
J'ai passé les commandes que tu m'as dit mais impossible d'accéder à la page login que ce soit sur le disque dur externe ou Mac sud
Pour information, j'ai redémarre le mac et je suis passé en single user . J'ai passé les commandes que tu m'as dit et j'ai tapé reboot puis alt au démarrage.
C'était donc bien une erreur en bonne et due forme.
Note que la petite commande echo $0 est un moyen simple et universel de savoir si la précédente commande s'est achevée correctement : c'est donc pratique.
Je vois que tu n'arrives toujours pas à démarrer complètement sur l'un ou l'autre support.
Quelque chose qui peut éventuellement aider à l'analyse, c'est de lire les journaux du système.
Comme ça ne démarre pas, tu ne peux pas utiliser l'utilitaire graphique pour les lire. Donc il faut aller les récupérer à la main : soit les lire sur la console, soit sur un autre ordinateur.
Le journal le plus important est sans doute system.log, avec son chemin complet : /private/var/log/system.log
Le fichier peut être un peu long, c'est pour cela qu'il serait plus simple de le parcourir sur un autre ordinateur, ou alors utiliser un éditeur comme nano (ou vi mais il est un peu difficile à prendre en main). Ou le visualiser avec une commande d'affichage comme more, qui affiche le fichier page à page (on passe d'une page à l'autre par appui sur la barre d'espace).
Pour faire simple, tu peux :
- supprimer le fichier :
- sur le disque interne :
Bloc de code:rm /private/var/log/system.log - sur le disque "Clone" :
Bloc de code:rm /Volumes/Clone/private/var/log/system.log
- sur le disque interne :
- redémarrer sur l'un ou l'autre des disques (suivant lequel tu veux débugger)
- puis redémarrer en mono-utilisateur
- et parcourir le fichier :
- avec un éditeur, ce serait :
ouBloc de code:nano /private/var/log/system.log
Bloc de code:nano /Volumes/Clone/private/var/log/system.log - en mode visualisation simple :
ouBloc de code:more /private/var/log/system.log
Bloc de code:more /Volumes/Clone/private/var/log/system.log
- avec un éditeur, ce serait :
M
Membre supprimé 1060554
Invité
J'ajoute ma petite variation -->
Voici le plan D de réserve --> avec le Mac de ta connaissance > télécharger de l'AppStore une installateur de High Sierra (5,7 Go) qui se logera dans les Applications. Par ailleurs > paramétrer une clé USB de 8 Go (ou plus) en GUID x jhfs+ exactement comme ton DDE actuel > choisir le nom de volume CLE (sans accent).
Tout cela fait > passer la commande (copier-coller) dans le Terminal de la session de l'autre Mac toujours (débloque le tapis roulant horizontal pour la voir jusqu'au bout) -->
=> en 10' environ tu auras une clé d'install démarrable de High Sierra. De quoi booter sur une session de secours (vérifier que le Mac boote dessus). Et réinstaller High Sierra après reformatage de Mac SSD et avant récupération des données de Clone si besoin est : une opération qui marche souvent très bien. J'ai dépanné des dizaines et dizaines de membres de MacGé avec ce procédé --> ils ont retrouvé leur session à l'identique de l'antérieure.
- super-"zarbi" : ça voudrait dire que tu ne parviens pas à obtenir l'écran du gestionnaire de démarrage (boot_manager) avec la touche "alt" ? --> impossible dans ces conditions de vérifier s'il y a une amélioration du démarrage sur l'un ou l'autre volume.
- tu peux redémarrer le Mac avec la commande reboot > mais le laisser démarrer tout seul ensuite --> voir si le gestionnaire de démarrage se réveille alors et finit par tenter le démarrage sur un volume
- tu peux passer la commande :
qui éteint le Mac. Puis le rallumer avec "alt" pressée. Ou à la rigueur l'éteindre de force (pression continue sur le bouton d'alimentation) puis rallumage avec "alt" presséeBloc de code:
shutdown -r now
Voici le plan D de réserve --> avec le Mac de ta connaissance > télécharger de l'AppStore une installateur de High Sierra (5,7 Go) qui se logera dans les Applications. Par ailleurs > paramétrer une clé USB de 8 Go (ou plus) en GUID x jhfs+ exactement comme ton DDE actuel > choisir le nom de volume CLE (sans accent).
Tout cela fait > passer la commande (copier-coller) dans le Terminal de la session de l'autre Mac toujours (débloque le tapis roulant horizontal pour la voir jusqu'au bout) -->
Bloc de code:
sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/CLE --applicationpath /Applications/Install\ macOS\ High\ Sierra.app --nointeraction- la commande paraît prolixe > mais se borne à appeler un exécutable createinstallmedia dans le paquetage de l'application téléchargée > de lui fournir l'adresse de la destination (CLE) > de la source (l'installateur) > et l'instruction de ne pas interagir avec l'opérateur pour reformater la clé au départ
=> en 10' environ tu auras une clé d'install démarrable de High Sierra. De quoi booter sur une session de secours (vérifier que le Mac boote dessus). Et réinstaller High Sierra après reformatage de Mac SSD et avant récupération des données de Clone si besoin est : une opération qui marche souvent très bien. J'ai dépanné des dizaines et dizaines de membres de MacGé avec ce procédé --> ils ont retrouvé leur session à l'identique de l'antérieure.
