Installer Yosemite sur un nouveau DD quand l'ancien est hors d'usage

[shindiana]

Bonjour à tous,

Je possède un MacBook Pro 13 pouces acheté en juin 2011 qui tournait il y a encore quelques heures sous Yosemite.

En pleine utilisation, l'écran s'est figé et j'ai du forcer des redémarrages qui aboutissaient systèmatiquement sur pomme> chargement de la barre > écran noir l'ordi s'éteint.

Impossible de démarrer en mode sans échec.

Je décide alors d'effacer mon disque via l'utilitaire (Cmd + R) et de réinstaller Yosemite de manière clean.
J'ai déjà opté pour cette solution par le passé et il est évident que mon disque dur est sur la fin et je ne stockais déjà plus rien dessus.

Seulement cette fois ci impossible de finaliser l'installation de l'OS malgré de nombreux essais..

J'aboutis toujours à "OS X n'a pas pu être installé sur l'ordinateur file system verify or repair failed"

Je précise qu'en effet avant d'effacer complètement mon disque j'avais tenté de le réparer via l'utilitaire de disque mais que celui ci me dit que c'est impossible bien qu'une réparation soit nécessaire.

Conclusion ==> il est temps de procéder à l'achat d'un nouveau disque dur.

Seulement je me retrouve avec un MacBook Pro avec un disque dur endommagé et vierge sans OS installé.

1/ Est-il possible d'utiliser un disque SSD ainsi qu'un boîtier externe pour le brancher en USB sur mon ordinateur puis d'y installer Yosemite via Cmd + R en téléchargeant via une connexion internet? Dois-je formater le disque avant?

2/ Si oui, le fait d'utiliser mon MBP avec un disque dur branché en USD présente-il d'autres inconvénients hormis le fait de devoir se trimballer un DD relié à un fil? (En terme de performance, traitement des données)

A terme si le 1/ et 2/ fonctionne je compte intégrer le SSD a l'intérieur du Mac mais pour le moment ma priorité est de redonner vie à ma machine.

Merci d'avance pour vos éclaircissements et conseils.

 

[Membre supprimé 1060554]

Bonjour Shindiana.

En réponse à ta question n°1 : effectivement, ton SSD vierge dans un boîtier connecté au Mac en USB, tu démarres sur ta «Recovery HD» encore fonctionnelle et dans l'«Utilitaire de Disque» tu sélectionnes le disque global (ligne supérieure, attenante à la marge) du SSD et tu actionnes l'option 'Effacer' --> par défaut, le SSD va être re-tablé en Table de Partition GUID et formaté en Mac OS étendu (journalisé) comme requis. Cela fait, tu lances la fonctionnalité : Réinstaller OS X qui te fait télécharger depuis les Serveurs Apple les Packages correspondant à la version d'OS X de ton disque dur défaillant. En fin de téléchargement, lorsque le programme d'installation te propose d'installer l'OS, tu choisis comme disque de destination ton SSD ré-initalisé comme il faut et en fin d'installation, ton Mac re-démarre automatiquement sur l'OS frais émoulu du SSD. Une «Recovery HD» invisible aura été installée sur une petite partition collatérale au volume de l'OS comme attendu.

Les processus de lecture / écriture au SSD externe s'effectuant via une connexion USB basique, il est clair que, si le dispositif en soi est exploitable, une perte notable de vitesse exécutive intervient. Je te conseille, sans plus tarder, d'ouvrir ton MacBook Pro et d'opérer la substitution SSD --> HDD. Comme tu peux le voir d'après ce tuto du site «iFixit» : ☞MacBook Pro 13" Unibody Early 2011 Hard Drive Replacement☜, l'intervention est aussi triviale que de manipuler un lego puéril.

Si tu fais d'entrée les frais d'un SSD d'une taille suffisante, tu t'éviteras les problématiques à "double disque interne" (SSD à la place du HDD + HDD à la place du Super-Drive) qui induisent fréquemment la solidarisation logique des deux disques par un «Fusion Drive» exportant un seul Volume Logique - ce qui, en langage clair, consiste dans la greffe d'un Groupe de Volumes Logiques : CoreStorage unique gérant les 2 disques physiques, sans qu'intervienne aucun gestionnaire intelligent des allocations d'écriture, mais une préférence aveugle du SSD dans un 1er temps par "facilité d'écriture au disque" ne conduisant au report d'écritures sur le HDD qu'à partir de la limite de saturation du SSD atteinte : procédé aveugle qui (à mon jugement du moins) équivaut à une escroquerie intellectuelle vectrice d'ennuis potentiels dans la pratique.

 

[shindiana]

Bonjour Macomniac.
Merci infiniment pour ta réponsécela répond à toutes mes questions, je sais quoi faire désormais!

 

[shindiana]

La manœuvre a marché avec un SSD Samsung EVO 250 go et un boîtier externe.
Aucun problème pour la réinstallation de l'OS.
En USB le disque est déjà notablement plus rapide que mon ancien DD d'origine qui fatigué.

Je vais me lancer demain dans la procédure pour intégrer le SSD à l'intérieur en espérant ne pas avoir de souci de nappe ce qui semble fréquent avec les MPB 2011...

Dois je utiliser le CD fourni par Samsung et installer je ne sais quel firmware ou drivers ou puis-je m'en passer à ce stade?

 

[Deleted member 1099514]

Salut

Pour les firmware EVO voir ICI avant de faire quoi que ce soit.
Si ton SSD fonctionne ne fais pas de MAJ pour l'instant.
Sur SSD non apple tu vas avoir le problème du Trim à valider ou non.
Si tu le valides, il y a qq précautions à prendre :
Avant toute mise à jour du système, ou démarrage en mode sans échec, bien penser à désactiver Trim Enabler sous peine de retrouver un "sens interdit" et d'être obligé de "bricoler" ou dans le pire des cas de refaire une install système, qui préserve tes données et programmes, mais est très longue, car via le net.

Pas de quoi prendre peur, car l'ajout d'un ssd va booster ta machine.

@+

 

[shindiana]

Salut

Pour les firmware EVO voir ICI avant de faire quoi que ce soit.
Si ton SSD fonctionne ne fais pas de MAJ pour l'instant.
Sur SSD non apple tu vas avoir le problème du Trim à valider ou non.
Si tu le valides, il y a qq précautions à prendre :
Avant toute mise à jour du système, ou démarrage en mode sans échec, bien penser à désactiver Trim Enabler sous peine de retrouver un "sens interdit" et d'être obligé de "bricoler" ou dans le pire des cas de refaire une install système, qui préserve tes données et programmes, mais est très longue, car via le net.

Pas de quoi prendre peur, car l'ajout d'un ssd va booster ta machine.

@+

Bonjour Jean,

Merci pour tes conseils et les indications.
Bien noté notamment pour la fonction TRIM.

 

[shindiana]

Petit message pour dire que j'ai installé le nouveau SSD en interne.

Effectivement, bien que les performances étaient satisfaisantes lorsque le SSD était connecté en USB via un boitier externe, là ça n'a tout simplement rien à voir.
Démarrage de l'ordi en une vingtaine de secondes, ordinateur beaucoup plus rapide.

Trim Enabler a bien été installé . Il faudra se rappeler de le désactiver en cas de MAJ de l'OS.

Jusqu'ici tout va bien hormis la température que je trouve plus élevée qu'avant (on est souvent aux alentours de 60-70° sans que j'ai de grosses applications ouvertes).

 

[Membre supprimé 1060554]

Salut encore shindiana.

Je vois que ton SSD en interne te donne satisfaction. J'ai moi-même remplacé le HDD de mon MacBook Pro Early_2011 par un SSD et je ne le regrette pas, car, mettant à jour régulièrement mon OS à la dernière version publique (actuellement «Yosemite 10.10.2»), les limitations du disque à plateaux ont commencé à se faire sérieusement sentir chez moi à partir de «Mountain Lion 10.8» pour devenir critiques avec «Mavericks 10.9» où j'ai jeté l'éponge...

♤​

En ce qui concerne l'activation du Trim via «Trim Enabler» (que j'ai moi-même opérée sur mon SSD), je n'ai pas constaté de danger particulier à exécuter une MÀJ d'OSX sans l'avoir désactivé au préalable. Parce qu'automatiquement «Trim Enabler» se trouve désactivé lors de cette opération, et c'est au re-démarrage du Mac après écriture de la MÀJ qu'une fois la session d'utilisateur ré-ouverte, «Trim Enabler» affiche une fenêtre demandant si l'on veut réactiver le Trim.

Le pourquoi de ce comment se laisse assez facilement comprendre : «Trim Enabler» modifie quelque octets de l'extension du noyau Apple en charge du Trim sur les SSD "Apple_natifs' : /System/Library/Extensions/IOAHCIFamily.kext afin de la rendre expoitable pour un SSD de Tierce-Partie + édite un argument de boot en NVRAM à : boot-args kext-dev-mode=1 pour neutraliser le protocole du kext_signing introduit avec «Yosemite» (contrôle d'intégrité des kexts Apple au boot) + met-à-jour le kernelcache de telle manière que le clone du code du kernel s'y trouve solidarisé des kexts en tant que "bloc d'extensions" bénéficiaire de l'option a priori : all_loaded (ce qui "shunte" un chargement discret avec examen préalable kext à kext) --> suite à quoi, on a droit à la séquence de boot : EFI--> NVRAM [= lecture du boot-args kext-dev-mode=1] --> exécution du Boot_Loader : boot.efi [avec passation de l'argument "kext-dev-mode=1" = ordre de ne pas chercher de poux dans la tignasse des extensions] --> chargement "holistique" du kernelcache at: /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache [au lieu d'une séquence "sans cache" : --> /System/Library/Kernels/kernel --> /System/Library/Extensions].

Lors d'une MÀJ d'OS X, il y a tout de suite ré-écriture du dossier intégral des kexts remplacées par leurs updates et donc la IOAHCIFamily.kext se trouve automatiquement restaurée et par suite le Trim désactivé ipso facto + les arguments de boot en NVRAM se trouvent ré-écrits aux valeurs par défaut + le ci-devant kernelcache se trouve supprimé a priori et le boot s'opère en mode "discret" --> RAS, puisque les kexts Apple sont toutes "intègres" (CQFD).

♧​

Non. Le danger ne vient pas à mon sens d'une MÀJ de l'OS. Il vient au contraire d'un réflexe acquis de l'utilisateur avec les OS antérieurs à «Yosemite» consistant ponctuellement à pratiquer un reset_NVRAM et/ou un démarrage en SAFE_MODE (dit : "sans extensions" ou "sans échec"). Parce que dans le 1er cas de figure, l'argument de boot "libéral" : boot-args kext-dev-mode=1 saute et se trouve remplacé par celui qui restaure le kext_signing --> cet argument passé par l'EFI au Boot_Loader : boot.efi suffit pour court-circuiter le chargement en bloc du kernelcache et lancer au contraire le chargement discret des kexts une à une avec examen individuel d'intégrité et hop! plantage arrivé à la IOAHCIFamily.kext modifiée (écran affichant le panneau d'interdiction de stationner ⊘). Et dans le 2è cas, le démarrage en SAFE_MODE supprimant entre autres les caches-Système, le kernelcache est supprimé au boot, les arguments de boot spéciaux en NVRAM suspendus et le Boot_Loader : boot.efi lance le chargement par le kernel solitaire de la série des kexts en mode discret --> et hop! plantage = ⊘ [J'ai personnellement expérimenté volontairement ces 2 occurrences, et le plantage est inéluctable].

Il faut donc se garder soigneusement lorsqu'il y a combinaison : [SSD de tierce-partie x «Yosemite» x «Trim Enabler» activé] de tout reset_NVRAM et/ou démarrage en SAFE_MODE mais aussi, regardant ce qui est impliqué par cette 2è option (la suppression du kernelcache), se garder de l'utilisation de tout logiciel de maintenance dans ses options de vidage des caches-Système sous peine de plantage automatique au re-démarrage. Il est à noter, sous ce regard, que seul le logiciel «Onyx 2.9.x» (les versions pour «Yosemite») intègre ce facteur problématique en ne présentant pas la case de "nettoyage des : caches système" cochée par défaut, mais assortie d'un avertissement de risques si Trim Enabler activé dans ses menus :

Nettoyage

&

Automation

♡
​

Il y a 3 manières de déplanter le Mac s'il y a lieu :

- a) via le «Terminal» de la «Recovery HD» comme préconisé par le développeur de «Trim Enabler» ici ☞Trim Enabler and Yosemite☜. Il est à noter que le procédé intitulé "Reversing any changes by Trim Enabler" ne sort pas un lapin d'un chapeau pour ce qui est de la restauration de la kext native : IOAHCIFamily.kext --> astucieusement, la commande proposée est une commande de re-copie à partir du sous-dossier /System/Library/Extensions du volume de la «Recovery HD» (parce que la «Recovery HD» repose en tant qu'affichage graphique sur une version d'OS X complète quoique allégée et donc intégrant l'essentiel des kexts à l'état intègre qui se retrouvent dans le dossier des Extensions de l'OS) vers le sous-dossier /Volumes/Macintosh\ HD/System/Library/Extensions d'OS X après suppression de la kext altérée. Le reste consiste à restaurer l'argument standard de boot en NVRAM, à re-synchroniser le dossier des Extensions et à recréer de neuf le kernelcache.

Cette méthode que j'ai expérimentée après plantage volontaire une dizaine de fois marche la plupart du temps mais pas dans tous les cas.


- b) ré-installer la version synchrone d'OS X (soit par la fonctionnalité "Ré-Installer OS X" de la «Recovery HD» - long - ; soit par démarrage sur un Système indépendant - clé ou OS - permettant de lancer le programme d'installation d'un Installer OS X Yosemite exactement synchrone de l'OS du disque du Mac - rapide = 20'.

Cette méthode, d'après mon expérience, est la seule qui réussisse à 100% à restaurer un OS bootable.


-3) dé-montage du SSD placé en interne et installation dans un boîtier USB --> le démarrage en mode externe supprime en effet le protocole du kext_signing qui ne s'applique qu'à un SSD de Tierce-Partie susbtitué en interne au HDD du Mac.

Cette méthode, qui implique un petit travail mécanique, mérite d'être mentionnée nonobstant, car elle peut assurer un démarrage en cas d'échec des commandes dans le «Terminal» de la «Recovery HD» et d'impossibilité de ré-installer l'OS même à partir de la «Recovery HD» (occurrences déjà attestées sur les forums) comme d'absence d'un clone démarrable par ailleurs.

Un clone de l'OS sur un DDE est évidemment toujours démarrable, mais un rétroclonage sur le SSD du Mac en cas de plantage ne restaure pas un Système bootable si l'argument "libéral" en NVRAM n'est pas restauré indépendamment du rétro-clonage.​

♡​

 

[shindiana]

Bonjour macomaniac,

Merci beaucoup pour ta réponse exhaustive et toutes ces précisions.

Effectivement comme toi depuis Lion je trouvais les réactions et les performances globales de ma machine très poussives. Très satisfait de ce côté là.

En ce qui concerne Trim Enabler, je flippais vraiment de ce cas de figure où je me disais qu'il fallait que je pense à le désactiver moi même en cas de maj de l'OS. Toutes ces informations sont les bienvenues , je suis désormais plus informé et serein.