Recovery HD après passage à SSD, et diverses interrogations...
- Créateur du sujet okeeb
- Date de début
Bonjour,
Merci Jeanjd63, cependant, au vu des soucis de jeunesse de Yosemite, et fort de quelques longues années d'expérience informatique qui m'auront montré qu'installer un nouveau système n'est pas toujours une fin en soi, je crois que je vais persister un peu encore sur Mavericks, peut être en lorgnant vers El Capitan et ses premiers balbutiements...
Okeeb.
Merci Jeanjd63, cependant, au vu des soucis de jeunesse de Yosemite, et fort de quelques longues années d'expérience informatique qui m'auront montré qu'installer un nouveau système n'est pas toujours une fin en soi, je crois que je vais persister un peu encore sur Mavericks, peut être en lorgnant vers El Capitan et ses premiers balbutiements...
Okeeb.
M
Membre supprimé 1060554
Invité
Salut okeeb.
Saperlipopette ! Je me suis amusé sur mon Mac, en démarrant sur l'OS «Yosemite» (mais la problématique est la même avec «Mavericks») à monter la «Recovery HD» correspondante et à en faire comme toi une image-disque .dmg sur mon Bureau. Puis j'ai effacé cette partition pour re-créer un système de fichiers jhfs+ vierge manipulable, je l'ai supprimée (càd. virée au statut de free_space hors partitionnement), enfin j'ai passé une commande pour faire récupérer ce free_space par le volume de mon OS. Je me suis retrouvé dans ton exacte situation : un volume de l'OS sans «Recovery HD», mais avec une image-disque de ses ressources (et le programme dmtest dans /bin chez moi).
J'ai monté le volume de mon image-disque .dmg en un volume : Recovery HD, puis j'ai passé exactement la commande que tu as utilisée (avec les / / non accollées) --> résultat : après un poignée de minutes, j'ai derechef une partition de récupération «Recovery HD» copie conforme de la précédente. Chez moi, la commande dmtest ensureRecoveryPartition a toujours marché.
D'où la question : pourquoi y a-t-il eu plantade chez toi ? Si j'exclus un facteur comme un "guignon" chronique (qui n'a pas de valeur assignable dans les processus informatiques - s'il peut en avoir une dans le domaines de l'imagination
), il me vient les conjectures suivantes :
.
[Ton image-disque .dmg de l'ancienne «Recovery HD», où est-elle localisée ? Sur ton Bureau de session ? Ou dans un volume auxliaire (genre : clé USB) que tu attaches au Mac ? Si c'était ce dernier cas, peux-tu faire une copie de ton .dmg sur le Bureau de ta session et monter le volume Recovery HD à partir de cette localisation pour voir si ça aide ?]
Saperlipopette ! Je me suis amusé sur mon Mac, en démarrant sur l'OS «Yosemite» (mais la problématique est la même avec «Mavericks») à monter la «Recovery HD» correspondante et à en faire comme toi une image-disque .dmg sur mon Bureau. Puis j'ai effacé cette partition pour re-créer un système de fichiers jhfs+ vierge manipulable, je l'ai supprimée (càd. virée au statut de free_space hors partitionnement), enfin j'ai passé une commande pour faire récupérer ce free_space par le volume de mon OS. Je me suis retrouvé dans ton exacte situation : un volume de l'OS sans «Recovery HD», mais avec une image-disque de ses ressources (et le programme dmtest dans /bin chez moi).
J'ai monté le volume de mon image-disque .dmg en un volume : Recovery HD, puis j'ai passé exactement la commande que tu as utilisée (avec les / / non accollées) --> résultat : après un poignée de minutes, j'ai derechef une partition de récupération «Recovery HD» copie conforme de la précédente. Chez moi, la commande dmtest ensureRecoveryPartition a toujours marché.
D'où la question : pourquoi y a-t-il eu plantade chez toi ? Si j'exclus un facteur comme un "guignon" chronique (qui n'a pas de valeur assignable dans les processus informatiques - s'il peut en avoir une dans le domaines de l'imagination
- a) non chargement de la partition. La partition «Recovery HD», aurait bien été créée, avec les fichiers correspondants, mais pour une raison quelconque le kernel n'aurait pas pris en charge cette modification du partitionnement en conservant le chargement de l'ancienne distribution (j'avoue : je ne crois pas trop à cette conjecture, mais faisons comme si...) --> dans ce cas, il suffit de re-démarrer le Mac pour forcer cette prise en charge du nouveau partitionnement.
Si tu re-démarres avec la touche "alt" pressée, est-ce que tu avises un volume : Récupération 10.9.5 à l'écran de choix du disque de démarrage ? Alternative : si tu re-démarres avec les touches ⌘R tenues pressées, est-ce que tu atteins l'environnement de la «Recovery HD» (la fenêtre des 4 Utilitaires OS X) ? Ou même : si tu as débogué ton «Utilitaire de Disque» (par la commande que je t'avais passée), est que tu la vois listée en grisé : Recovery HD sous le volume Macintosh HD de ton OS ? Idem si dans le «Terminal», tu récidives la commande : diskutil list --> est que tu vois listée une : 3: Apple_Boot Recovery HD 650.0 MB disk0s3 ?
- b) problème à la vérification préalable de l'image-disque BaseSystem.dmg et du système de fichiers de l'OS (conjecture à n'explorer que si l'examen précédent constate une absence de «Recovery HD» après re-démarrage). Tu te souviens : je t'ai mis les 2 valeurs booléennes : 0 0 stipulant, la 1ère de ne pas vérifier l'image-disque .dmg avant emploi, et la 2è de vérifier sans réparer le système de fichiers de la partition de l'OS à re-partitionner.
☞ je sens venir la Bérézina du dmtest... Si tu re-démarres avec la touche "alt" pressée, est-ce que tu avises un volume : Récupération 10.9.5 à l'écran de choix du disque de démarrage ? Alternative : si tu re-démarres avec les touches ⌘R tenues pressées, est-ce que tu atteins l'environnement de la «Recovery HD» (la fenêtre des 4 Utilitaires OS X) ? Ou même : si tu as débogué ton «Utilitaire de Disque» (par la commande que je t'avais passée), est que tu la vois listée en grisé : Recovery HD sous le volume Macintosh HD de ton OS ? Idem si dans le «Terminal», tu récidives la commande : diskutil list --> est que tu vois listée une : 3: Apple_Boot Recovery HD 650.0 MB disk0s3 ?
--------------------
- b) problème à la vérification préalable de l'image-disque BaseSystem.dmg et du système de fichiers de l'OS (conjecture à n'explorer que si l'examen précédent constate une absence de «Recovery HD» après re-démarrage). Tu te souviens : je t'ai mis les 2 valeurs booléennes : 0 0 stipulant, la 1ère de ne pas vérifier l'image-disque .dmg avant emploi, et la 2è de vérifier sans réparer le système de fichiers de la partition de l'OS à re-partitionner.
- b1) pour ce qui est du 2è 0, il est impossible de mentionner 1 (= réparer si nécessaire le système de fichiers), car il s'agit de celui de l'OS démarré et donc monté en volume. Or, pour réparer un système de fichiers (et pas seulement le vérifier), il faut le démonter, ce qui est impossible pour celui de l'OS démarré. Serait-il possible que le système de fichiers de ton volume Macintosh HD comporte des erreurs, qui, en l'absence de réparation, bloqueraient le re-partitionnement ? Alors, pour débloquer la situation il faut pouvoir réparer ce système de fichiers de l'OS.
Tu peux (re)démarrer ton Mac les touches ⌘S tenues pressées, jusqu'à affichage du «Terminal» du Single User (root) = tableau noir dans lequel défilent les lignes blanches décrivant un pré-chargement sommaire. À la fin, tout doit s'immobiliser sur l'invite de commande : -bash-3.2# qui est un shell de root. Si les lignes s'arrêtent sans que tu touches cette invite, un coup de ↩︎ (pression sur la touche "Entrée" du clavier) te l'affichera. Saisis alors : fsck -fy (attention : le clavier est en QWERTY --> saisir : fsck )fy) et ↩︎ --> le programme fsck_hfs lance la vérification du système de fichiers de l'OS encore non-monté et sa réparation forcée si besoin. Tant que tu n'as pas, avant le ré-affichage de -bash-3.2#, mention d'un: the volume Macintosh HD appears to be OK, tu récidives ta commande autant de fois que nécessaire pour atteindre le OK.
Autre méthode (plus simple mais moins radicale en terme de réparation du système de fichiers, car une seule passe de réparation est effectuée) : tu démarres la touche ⇧ (maj) pressée = démarrage en "Safe Mode" (sans danger chez toi qui a activé le TRIM car tu es sous «Mavericks» qui ne connaît pas le kext_signing - lequel rendait problématique cette option dans les premières versions de «Yosemite» avant inroduction d'une parade par Apple) --> entre autres actions, le système de fichiers de l'OS est vérifié/réparé par le programme fsck_hfs avant re-montage. Comme tu débouches sur un OS avec pas mal d'extensions désactivées, il convient que tu re-démarres une nouvelle fois de façon normale pour toucher une session dans un OS aux extensions complètement chargées.
--> ces procédés devraient pallier le problème éventuel d'erreurs du système de fichiers de l'OS et cautionner la 2è option booléenne 0 dans la commande.
----------------------------------------------------------------------------------
- b2) pour ce qui est du 1er 0 (vérifier l'image-disque .dmg), il est possible de mentionner 1 (effectuer la vérification), sachant que le système de fichiers de ce disque virtuel est en lecture seule et insusceptible d'aucune réparation. À partir de la mince conjecture suivante : pour monter en volume un disque virtuel .dmg, il faut l'attacher au Système (exactement comme si on connectait une clé USB au Mac) et cet "attachement" dépend régulièrement d'une vérification préalable du système de fichiers impliqué. Chez moi, dmtest a toujours fait son travail avec les options 0 0, mais qui sait ? La mention : « Error (async): Couldn't attach disk image (-69736) » me laisse perplexe => voudrait-elle dire : impossible d'attacher le .dmg : BaseSystem.dmg et donc de monter son système de fichiers, par absence de protocole de vérification préliminaire ?
--> si donc la «Recovery HD» n'a pas été créée la première fois (conjecture a), et si tu as vérifié/réparé le système de fichiers de l'OS (via le Single User par exemple) pour que l'option booléenne 0 de rigueur reste sans incidences ; alors il doit être possible d'introduire une valeur 1 pour ce qui est de la vérification préalable de l'image-disque BaseSystem.dmg. Tu pourrais donc passer la commande qui convient à la localisation actuelle de ton dmtest (Bureau ou répertoire invisible /bin) parmi ces deux-ci :
--> est-ce qu'à la fin tu obtiens une partition «Recovery HD» ?
-----------------------------------------------------------------------------------
Tu peux (re)démarrer ton Mac les touches ⌘S tenues pressées, jusqu'à affichage du «Terminal» du Single User (root) = tableau noir dans lequel défilent les lignes blanches décrivant un pré-chargement sommaire. À la fin, tout doit s'immobiliser sur l'invite de commande : -bash-3.2# qui est un shell de root. Si les lignes s'arrêtent sans que tu touches cette invite, un coup de ↩︎ (pression sur la touche "Entrée" du clavier) te l'affichera. Saisis alors : fsck -fy (attention : le clavier est en QWERTY --> saisir : fsck )fy) et ↩︎ --> le programme fsck_hfs lance la vérification du système de fichiers de l'OS encore non-monté et sa réparation forcée si besoin. Tant que tu n'as pas, avant le ré-affichage de -bash-3.2#, mention d'un: the volume Macintosh HD appears to be OK, tu récidives ta commande autant de fois que nécessaire pour atteindre le OK.
Autre méthode (plus simple mais moins radicale en terme de réparation du système de fichiers, car une seule passe de réparation est effectuée) : tu démarres la touche ⇧ (maj) pressée = démarrage en "Safe Mode" (sans danger chez toi qui a activé le TRIM car tu es sous «Mavericks» qui ne connaît pas le kext_signing - lequel rendait problématique cette option dans les premières versions de «Yosemite» avant inroduction d'une parade par Apple) --> entre autres actions, le système de fichiers de l'OS est vérifié/réparé par le programme fsck_hfs avant re-montage. Comme tu débouches sur un OS avec pas mal d'extensions désactivées, il convient que tu re-démarres une nouvelle fois de façon normale pour toucher une session dans un OS aux extensions complètement chargées.
--> ces procédés devraient pallier le problème éventuel d'erreurs du système de fichiers de l'OS et cautionner la 2è option booléenne 0 dans la commande.
----------------------------------------------------------------------------------
- b2) pour ce qui est du 1er 0 (vérifier l'image-disque .dmg), il est possible de mentionner 1 (effectuer la vérification), sachant que le système de fichiers de ce disque virtuel est en lecture seule et insusceptible d'aucune réparation. À partir de la mince conjecture suivante : pour monter en volume un disque virtuel .dmg, il faut l'attacher au Système (exactement comme si on connectait une clé USB au Mac) et cet "attachement" dépend régulièrement d'une vérification préalable du système de fichiers impliqué. Chez moi, dmtest a toujours fait son travail avec les options 0 0, mais qui sait ? La mention : « Error (async): Couldn't attach disk image (-69736) » me laisse perplexe => voudrait-elle dire : impossible d'attacher le .dmg : BaseSystem.dmg et donc de monter son système de fichiers, par absence de protocole de vérification préliminaire ?
--> si donc la «Recovery HD» n'a pas été créée la première fois (conjecture a), et si tu as vérifié/réparé le système de fichiers de l'OS (via le Single User par exemple) pour que l'option booléenne 0 de rigueur reste sans incidences ; alors il doit être possible d'introduire une valeur 1 pour ce qui est de la vérification préalable de l'image-disque BaseSystem.dmg. Tu pourrais donc passer la commande qui convient à la localisation actuelle de ton dmtest (Bureau ou répertoire invisible /bin) parmi ces deux-ci :
Bloc de code:
sudo Desktop/dmtest ensureRecoveryPartition / /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg 1 0 /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist
sudo /bin/dmtest ensureRecoveryPartition / /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg 1 0 /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist--> est-ce qu'à la fin tu obtiens une partition «Recovery HD» ?
-----------------------------------------------------------------------------------
[Ton image-disque .dmg de l'ancienne «Recovery HD», où est-elle localisée ? Sur ton Bureau de session ? Ou dans un volume auxliaire (genre : clé USB) que tu attaches au Mac ? Si c'était ce dernier cas, peux-tu faire une copie de ton .dmg sur le Bureau de ta session et monter le volume Recovery HD à partir de cette localisation pour voir si ça aide ?]
Dernière édition par un modérateur:
D
Deleted member 1099514
Invité
Ça marche aussi pour Maverick. Il faut simplement le télécharger et qu'il soit présent dans le dossier Applications.
Télécharger Mavericks ? Je m'étais penché sur la question il y a quelques temps, mais je n'y suis jamais parvenu. C'était le système livré à l'origine avec mon MbP, il n'apparaît donc pas dans mes achats, et n'est pas disponible sur l'AppStore (ou alors j'ai mal regardé). Mais il est certain que cela serait intéressant d'en avoir une copie pour plus tard.
Bon, l'image disque de ma Recovery ainsi que dmtest sont sur le bureau depuis le début, image évidemment montée. J'ai procédé à l'opération de maintenance via fsck -fy, aucun souci à noter, arrivée à "OK" du premier coup. Ensuite tentative de recréer la Recovery via les l'une, puis l'autre ligne de commande et
macbook-pro-de-franck:~ franckguillotin$ sudo /bin/dmtest ensureRecoveryPartition / /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg 1 0 /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist
Donor=disk0s2 Image=/Volumes/Recovery HD/com.apple.recovery.boot/BaseSystem.dmg DoVerifyImage=1 DoRepairDonor=0
ChunkList=/Volumes/Recovery HD/com.apple.recovery.boot/BaseSystem.chunklist
Creating recovery partition: async call initiate
Creating recovery partition: async call exit success; operation now in progress
->-[Local dmAsyncStartedForDisk:]: del callback: DADR=0x7fcd536095c0
<--[Local dmAsyncStartedForDisk:]
->-[Local dmAsyncMessageForDisk:string:dictionary:]: del callback: DADR=0x7fcd53609730=disk0s2 str=Attaching and verifying disk image /Volumes/Recovery HD/com.apple.recovery.boot/BaseSystem.dmg dict=(null)
<--[Local dmAsyncMessageForDisk:string:dictionary:]
->-[Local dmAsyncProgressForDisk:barberPoleercent:]: del callback: DADR=0x0=(null) pole/pct=0/6.000000
<--[Local dmAsyncProgressForDisk:barberPole
->-[Local dmAsyncProgressForDisk:barberPole
<--[Local dmAsyncProgressForDisk:barberPole
->-[Local dmAsyncFinishedForDisk:mainError:detailError:dictionary:]: del callback: DADR=0x7fcd5340a9b0=disk0s2 errMain=-69736 errAux=0 infoDict=(null)
<--[Local dmAsyncFinishedForDisk:mainError:detailError:dictionary:]
Creating recovery partition: finished
Error (async): Couldn't attach disk image (-69736)
macbook-pro-de-franck:~ franckguillotin$
/QUOTE]
Je crois que je vais continuer d'utiliser Time Machine et mon clone, ne perdez pas inutilement votre temps sur ce point de détail...
Voilà comment sont positionnés les deux éléments nécessaires à cette Recovery HD... Rien de bizarre. C'est à n'y rien comprendre.
https://www.dropbox.com/s/nbklpgtxrxlcgwx/Capture d'écran 2015-07-24 06.26.54.jpg?dl=0
https://www.dropbox.com/s/nbklpgtxrxlcgwx/Capture d'écran 2015-07-24 06.26.54.jpg?dl=0
Dernière édition:
D
Deleted member 1099514
Invité
Salut
Je la tenterai + simple :
copier sur le bureau les 2 fichiers :
BaseSystem.dmg
et
BaseSystem.chunklist
puis passer la commande :
Je la tenterai + simple :
copier sur le bureau les 2 fichiers :
BaseSystem.dmg
et
BaseSystem.chunklist
puis passer la commande :
Bloc de code:
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
M
Membre supprimé 1060554
Invité
Salut encore okeeb.
J'ai réussi à reproduire exactement ton erreur : quand aucun disque virtuel BaseSystem.dmg n'existe au bout de l'adresse mentionnée dans la commande => j'obtiens un "coulnd't attach diskimage" : impossible d'attacher au système l'image-disque [car aucune image-disque du nom indiqué trouvée au bout du chemin indiqué]. Est-ce que ce ne serait pas le cas chez toi ? Après avoir monté ton disque «Recovery HD.img» en un volume Recovery HD (tu ne trouves pas curieux d'utiliser une extension .img qui n'a plus cours depuis «MacOS 9» au lieu de .dmg ?), est-ce que la commande :
retourne une liste d'éléments dans laquelle tu vois nommément un : BaseSystem.dmg (et bien sûr aussi une BaseSystem.chunklist) ?
- si non --> cf. mon téléchargement ci-dessous.
- si oui --> tu peux faire une copie des 2 éléments sur ton Bureau comme préconisé par Jean par la commande :
et comme le BaseSystem.dmg, s'il existe bien, doit être invisible (et peut-être aussi la BaseSystem.chunklist) - tu les démasques sur ton Bureau par la commande :
=> est-ce que tu as bien tes 2 éléments visibles sur le Bureau : BaseSystem.dmg & BaseSystem.chunklist ?
Alors, passe la commande (version Jean) :
--> est-ce que ça marche ?
Sinon, j'ai mis au point un plan spécial : « SOS_okeeb ». J'ai chargé un dossier dans ma DropBox recelant le BaseSystem.dmg et le BaseSystem.chunklist de la «Recovery HD» de mon «Mavericks 10.9.5» + derechef un exemple du dmtest. Tu peux le télécharger ici : ☞RECO1095.zip☜. Une fois téléchargé (477,7 Mo), arrange-toi pour que le dossier dézippé RECO1095 réside sur ton Bureau de session. Il y a 3 éléments dans ce dossier : l'image-disque BaseSystem.dmg, le fichier BaseSystem.chunklist et derechef le programme UNIX dmtest).
Cela fait, il ne te reste plus qu'à passer la commande :
--> ne me dis pas que ça ne le fait pas, hein !
J'ai réussi à reproduire exactement ton erreur : quand aucun disque virtuel BaseSystem.dmg n'existe au bout de l'adresse mentionnée dans la commande => j'obtiens un "coulnd't attach diskimage" : impossible d'attacher au système l'image-disque [car aucune image-disque du nom indiqué trouvée au bout du chemin indiqué]. Est-ce que ce ne serait pas le cas chez toi ? Après avoir monté ton disque «Recovery HD.img» en un volume Recovery HD (tu ne trouves pas curieux d'utiliser une extension .img qui n'a plus cours depuis «MacOS 9» au lieu de .dmg ?), est-ce que la commande :
Bloc de code:
ls /Volumes/Recovery\ HD/com.apple.recovery.bootretourne une liste d'éléments dans laquelle tu vois nommément un : BaseSystem.dmg (et bien sûr aussi une BaseSystem.chunklist) ?
- si non --> cf. mon téléchargement ci-dessous.
- si oui --> tu peux faire une copie des 2 éléments sur ton Bureau comme préconisé par Jean par la commande :
Bloc de code:
cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg Desktop && cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist Desktopet comme le BaseSystem.dmg, s'il existe bien, doit être invisible (et peut-être aussi la BaseSystem.chunklist) - tu les démasques sur ton Bureau par la commande :
Bloc de code:
sudo chflags nohidden Desktop/BaseSystem.dmg && sudo chflags nohidden Desktop/BaseSystem.chunklist=> est-ce que tu as bien tes 2 éléments visibles sur le Bureau : BaseSystem.dmg & BaseSystem.chunklist ?
Alors, passe la commande (version Jean) :
Bloc de code:
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist--> est-ce que ça marche ?
--------------------
Sinon, j'ai mis au point un plan spécial : « SOS_okeeb ». J'ai chargé un dossier dans ma DropBox recelant le BaseSystem.dmg et le BaseSystem.chunklist de la «Recovery HD» de mon «Mavericks 10.9.5» + derechef un exemple du dmtest. Tu peux le télécharger ici : ☞RECO1095.zip☜. Une fois téléchargé (477,7 Mo), arrange-toi pour que le dossier dézippé RECO1095 réside sur ton Bureau de session. Il y a 3 éléments dans ce dossier : l'image-disque BaseSystem.dmg, le fichier BaseSystem.chunklist et derechef le programme UNIX dmtest).
Cela fait, il ne te reste plus qu'à passer la commande :
Bloc de code:
sudo ~/Desktop/RECO1095/dmtest ensureRecoveryPartition / ~/Desktop/RECO1095/BaseSystem.dmg 0 0 ~/Desktop/RECO1095/BaseSystem.chunklist--> ne me dis pas que ça ne le fait pas, hein !
--------------------
RRRRhhhhaaa les "sauveteurs de l'extrême" !!! Je tente cela dès que possible, mais même avant de vérifier si cela fonctionne (ce dont je ne doute pas !), un grand merci !
Par faignantise, j'ai réalisé l'image disque alors que l'ancien HDD de mon MbP était connecté en externe à ma station Linux, qui utilise ce format...
Mes amis, je vous transmets mes plus sincères remerciements, cela a fonctionné comme sur des roulettes !
https://www.dropbox.com/s/4rkekjdy6lpjixu/Capture d'écran 2015-07-26 12.43.57.jpg?dl=0
https://www.dropbox.com/s/4rkekjdy6lpjixu/Capture d'écran 2015-07-26 12.43.57.jpg?dl=0
M
Membre supprimé 1060554
Invité
Salut okeeb.
Je vois, d'après ta capture, que tu as dû recourir au dossier que j'avais mis en téléchargement. Confirmation de ce que tu soupçonnais (message #21) :
☞ je pense que l'image-disque du volume monté de ta «Recovery HD» que tu avais faite sous «Linux» (format .img) ne contenait pas de ressources utilisables sous «Mac OS X» (d'où le message : "Could'nt attach disk-image" concernant le BaseSystem.dmg inclus). Dès que le programme dmtest a disposé, par contre, de sources valides, il a créé sans barguigner une partition de récupération...
Je vois, d'après ta capture, que tu as dû recourir au dossier que j'avais mis en téléchargement. Confirmation de ce que tu soupçonnais (message #21) :
Je soupçonne mon image disque d'être de piètre qualité
☞ je pense que l'image-disque du volume monté de ta «Recovery HD» que tu avais faite sous «Linux» (format .img) ne contenait pas de ressources utilisables sous «Mac OS X» (d'où le message : "Could'nt attach disk-image" concernant le BaseSystem.dmg inclus). Dès que le programme dmtest a disposé, par contre, de sources valides, il a créé sans barguigner une partition de récupération...
Grand merci encore une fois, j'en ai profité pour sauvegarder le dossier RECO1095 agrémenté de la commande terminal, cela pourra toujours se révéler utile à l'avenir...
Okeeb.
Okeeb.
Sujets similaires
10.15 Catalina
Clonage HDD vers SSD plus petit
