Nan:bored:
J'ai pris la peine de citer et mettre le lien du pourquoi du comment, dans mon précédent message (#38) suffit de lire ........ :meh: c'est certainement trop te demander
Dernière édition:
10.13 High Sierra transition Yosemite - High Sierra (problème "installer")
- Créateur du sujet christophe59c
- Date de début
J'ai pris la peine de citer et mettre le lien du pourquoi du comment, dans mon précédent message (#38) suffit de lire ........ :meh: c'est certainement trop te demander
M
Membre supprimé 1060554
Invité
Salut Christophe
À l'époque de «Mavericks 10.9» (disons) --> la seule manière d'activer le TRIM sur des SDD de tierce-partie consistait à patcher (modifier quleques octets de) la kext (extension du kernel) Apple gérant le TRIM sur les SSD d'usine. C'est par exemple ce que réalisait le logiciel «Trim Enabler».
Cette manipulation a été rendue folklorique à l'époque de «Yosemite 10.10» --> car un protocole de sécurité dit "kext_signing" faisait vérifier au boot_loader (démarreur d'OS) boot.efi les extensions Apple natives avant de les injecter dans le kernel > donc arrivé à l'extension Apple gérant le TRIM et constatant qu'elle était bidouillée --> le boot.efi déclarait "stop !" et affichait un signe d'interdiction de stationner.
L'inscription en NVRAM d'un argument de type "développeur" (autorisant le démarrage expérimental d'un OS avec des extensions trafiquées) > plus quelques magouilles consistant à présenter au boot.efi le lot des extensions comme un paquet-cadeau conforme (bien emballé dans un cache de démarrage avec un sceau temporel conforme etc.) --> permettaient de démarrer l'OS sans plantage avec l'extension Apple bidouilllée.
Avec la version de l'OS «Yosemite 10.10.4» --> Apple a introduit en natif une extension destinée à gérer le TRIM sur les SSD tiers. Cette nouvelle extension ne fait pas partie par défaut du dossier des Extensions (étant donné qu'elle n'est pas requise pour ceux qui n'ont pas de SSD ou qui ont un SSD Apple) mais est localisée at : /System/Library/Filesysems/ AppleDataSetManagement.kext. La commande spécifique : sudo trimforce enable permet d'en réaliser une copie dans le dossier-Système des Extensions. Suite à quoi > au prochain démarrage > le boot.efi injectera dans le kernel la nouvelle extension avec toutes les autres.
[Pour les amateurs d'énigmes : l'utilitaire trimforce possède un privilège d'usine inouï --> il est capable de modifier le dossier-Système des Extensions alors même que le SIP est activé et verrouille en principe ce répertoire contre toute modification. C'est un des rares utilitaires capables de traverser les flags du SIP en pouvant opérer une copie d'extension dans le répertoire verrouillé des Extensions.]
Cette extension 100% Apple avec la commande qui la rend opérationnelle a du jour au lendemain renvoyé le patch de l'extension Apple pour SDD d'usine et les instructions "développeur" au démarrage pour passer le kext_signing --> au rayon des bricolages épiques du concours Lépine.
Le développer de «Trim Enabler» a été conduit à créer une extension de tierce partie qui se localise dans le dossier des Extensions tierces de la Bibliothèque Générale --> pour gérer le TRIM de manière régulière. À quoi bon cette extension alternative > puisque une extension 100 % Apple existe déjà ? - je ne connais pas le logiciel «Chameleon» --> mais je présume que son destin a dû suivre la même courbe nécessaire que celle de son concurrent «Trim Enabler». Le même « À quoi bon ? » s'adresse donc aussi bien à ce logiciel.
À l'époque de «Mavericks 10.9» (disons) --> la seule manière d'activer le TRIM sur des SDD de tierce-partie consistait à patcher (modifier quleques octets de) la kext (extension du kernel) Apple gérant le TRIM sur les SSD d'usine. C'est par exemple ce que réalisait le logiciel «Trim Enabler».
Cette manipulation a été rendue folklorique à l'époque de «Yosemite 10.10» --> car un protocole de sécurité dit "kext_signing" faisait vérifier au boot_loader (démarreur d'OS) boot.efi les extensions Apple natives avant de les injecter dans le kernel > donc arrivé à l'extension Apple gérant le TRIM et constatant qu'elle était bidouillée --> le boot.efi déclarait "stop !" et affichait un signe d'interdiction de stationner.
L'inscription en NVRAM d'un argument de type "développeur" (autorisant le démarrage expérimental d'un OS avec des extensions trafiquées) > plus quelques magouilles consistant à présenter au boot.efi le lot des extensions comme un paquet-cadeau conforme (bien emballé dans un cache de démarrage avec un sceau temporel conforme etc.) --> permettaient de démarrer l'OS sans plantage avec l'extension Apple bidouilllée.
Avec la version de l'OS «Yosemite 10.10.4» --> Apple a introduit en natif une extension destinée à gérer le TRIM sur les SSD tiers. Cette nouvelle extension ne fait pas partie par défaut du dossier des Extensions (étant donné qu'elle n'est pas requise pour ceux qui n'ont pas de SSD ou qui ont un SSD Apple) mais est localisée at : /System/Library/Filesysems/ AppleDataSetManagement.kext. La commande spécifique : sudo trimforce enable permet d'en réaliser une copie dans le dossier-Système des Extensions. Suite à quoi > au prochain démarrage > le boot.efi injectera dans le kernel la nouvelle extension avec toutes les autres.
[Pour les amateurs d'énigmes : l'utilitaire trimforce possède un privilège d'usine inouï --> il est capable de modifier le dossier-Système des Extensions alors même que le SIP est activé et verrouille en principe ce répertoire contre toute modification. C'est un des rares utilitaires capables de traverser les flags du SIP en pouvant opérer une copie d'extension dans le répertoire verrouillé des Extensions.]
Cette extension 100% Apple avec la commande qui la rend opérationnelle a du jour au lendemain renvoyé le patch de l'extension Apple pour SDD d'usine et les instructions "développeur" au démarrage pour passer le kext_signing --> au rayon des bricolages épiques du concours Lépine.
Le développer de «Trim Enabler» a été conduit à créer une extension de tierce partie qui se localise dans le dossier des Extensions tierces de la Bibliothèque Générale --> pour gérer le TRIM de manière régulière. À quoi bon cette extension alternative > puisque une extension 100 % Apple existe déjà ? - je ne connais pas le logiciel «Chameleon» --> mais je présume que son destin a dû suivre la même courbe nécessaire que celle de son concurrent «Trim Enabler». Le même « À quoi bon ? » s'adresse donc aussi bien à ce logiciel.
Oui j'ai lu mais ne maitrisant pas tout les termes, je n'ai pas bien saisi la différence, en cherchant un peu sur le net je vois à peu près ce que cela veut dire, mais en applications? quelqu'un aurait un exemple concret? (car pour moi pour l'instant, du moment que c'est écrit trim enable... je suis incapable de faire la différence)
C'est une simple commande via le Terminal, pas un logiciel qui travaillera en tâche de fond en ne sachant pas ce qu'il fait (dans ton dos) !
M
Membre supprimé 1138547
Invité
Tu as le choix :
- Ouvrir la porte en passant le bras par la boite aux lettres afin d'atteindre la poignée interne, avec le risque de rester coincé + l'amputation du bras (solution Chameleon)
- Ouvrir la porte de l'extérieur avec la clé (solution Apple).
Sur le fond le résultat est le même, mais le risque est bien différent.
- Ouvrir la porte en passant le bras par la boite aux lettres afin d'atteindre la poignée interne, avec le risque de rester coincé + l'amputation du bras (solution Chameleon)
- Ouvrir la porte de l'extérieur avec la clé (solution Apple).
Sur le fond le résultat est le même, mais le risque est bien différent.
Je me suis mal exprimer, j'ai bien compris la différence entre soft et méthode Apple, mais quels sont les risques concrètement, système qui plante? logiciel ralentit? ordinateur qui explose? lol
M
Membre supprimé 1060554
Invité
ChristopheActuellement donc > le procédé Apple et un procédé de tierce partie («Trim Enabler» ou «Chameleon») pour gérer le TRIM --> se distinguent seulement par le fait que le procédé Apple loge une extension (pilote) maison dans le dossier /System/ Library/Extensions et que le procédé tiers loge une extension (pilote) tierce dans le dossier /Library/Extensions.
L'un ou l'autre pilote se trouve injecté dans le kernel au démarrage et le TRIM est donc géré de manière équivalente (par une kext ou pilote du kernel).
Je pense que tes interlocuteurs dans ce fil sont partis d'un constat simple (qui est aussi le mien d'ailleurs) : pourquoi payer pour un logiciel tiers pemettant l'injection d'un pilote tiers dans le kernel > alors qu'il existe un pilote Apple gratuit (activé par une simple commande) pour faire la même chose ? - d'autant qu'on serait plutôt tentés de faire davantage confiance à l'ingéniérie d'équipe Apple qu'à un développeur tiers individuel en matière de kext ?
Je pense que ça ne va pas plus loin.
Dernière édition par un modérateur:
D'accord, je n'avais pas compris comme ça du tout.
L’ingénierie commerciale d'un fabriquant (quel-qu’il soit) pour moi est du marketing, je leur fait rarement confiance, je suis dévenu méfiant vis à vis des dernières maj comme sur l'Iphone... mais c'est un autre sujet...
Chameléon se trouve tout à fait gratuitement
L’ingénierie commerciale d'un fabriquant (quel-qu’il soit) pour moi est du marketing, je leur fait rarement confiance, je suis dévenu méfiant vis à vis des dernières maj comme sur l'Iphone... mais c'est un autre sujet...
Chameléon se trouve tout à fait gratuitement
C'est celui que j'utilisais à l'époque, mais pourquoi utiliser à l'heure actuelle un logiciel qui monopolise des ressources alors qu'une simple commande via le Terminal fait la même chose ?
Finalement après toutes ces réponses je n'ai pas encore osé passer sur High Sierra sans upgrade de matériel.
Mais quelles sont les différences entre Yosémite et High Sierra? je vois des vidéos sur Youtube et autres mais je ne vois rien de diffèrent
Mais quelles sont les différences entre Yosémite et High Sierra? je vois des vidéos sur Youtube et autres mais je ne vois rien de diffèrent
Hé ! hé ! tu as un pseudo intallateur de 22 Mo au lieu des 5 Go réglementaires.
Cet article de MacGé avait signalé la facétie lors de la première livraison publique de High Sierra : ☞High Sierra : le premier petit installeur n'était apparemment pas le bon☜
Il faudrait que tu télécharges un installateur qui "fasse le poids"---> cherche sur l'App Store un autre onglet qui te permette ce téléchargement.
macomaniacJ'ai retrouvé ce sujet aujourd'hui en voulant passer de Yosemite à High Sierra : je n'ai jamais trouvé de lien sur l'App Store pour charger l'installeur complet.
Alors, j'ai mis à niveau d'abord vers Sierra, puis j'ai lancé l'installeur complet que j'avais récupéré au premier clic dans l'App Store à partir de mon second Mac, sous El Capitan…
Il semble donc y avoir une limitation délibérée de la part d'Apple : avant 10.11, on télécharge un mini-installer qui lance plus tard l'arrivée de l'installeur complet.
Je voulais l'installeur complet pour installer 10.13 en HFS+ (et sans CoreStorage) sur mes SSD : c'est fait !
Tu l'as peut-être constaté par ailleurs : sous 10.13, la commande de désactivation du CoreStorage (sudo diskutil coreStorage revert) ne prend effet qu'après un redémarrage (alors qu'elle est instantanée en 10.12).
M
Membre supprimé 1060554
Invité
François- Il y aurait donc une règle à cette absurdité : tout dépendrait de la version de l'OS du volume démarré. Merci pour cette précision.
- Tu as utilisé la commande startosinstall alors - je suppose. Est-ce que tu vois un avantage à installer High Sierra en jhfs+ au lieu d'apfs sur un SDD (à part un motif de prudence) ? - mes essais personnels avaient révélé un débit en lecture / écriture moitié moindre pour un volume 10.13 jhfs+ par rapport à un volume 10.13 apfs. Ça m'avait refroidi.
- Non : ça m'avait échappé. Le CoreStorage réversible généré par un installateur (sans FileVault ni Fusion Drive) se fait rare et ça fait un bon moment que je n'ai pas passé (ou fait passer sur les forums) de commande de réversion.
Je suis très (trop) prudent : maintenant que ma vieille imprimante est décédée de mort naturelle (2006-2918),
je passe à la dernière version stable de macOS, mais en gardant mes vieux repères (ni FV, ni Fusion Drive, ni APFS, ni CoreStorage),
car je ne maîtrise pas l'APFS.
Mais j'y viendrai un jour, sûrement !
Certes, quand je vois à quelle vitesse et avec quelle facilité j'ai mis aujourd'hui à niveau mes deux Mac vers High Sierra, je me dis que je m'inquiète pour rien.
Et que mes débits remonteraient alors (faudrait que je les vérifie, mais mon Mac de tous les jours a de la marge !).
Bonne soirée à toi.
Sujets similaires
10.13 High Sierra
Problème de réinstallation MacOS High Sierra MBP 2011
