Reconstruire le cache Système sous OS X/macOS, Et en bonus, vérifier/Réparer les permissions sous OS X 10.11 El Cap

[polyzargone]

Le cache Système et le prelinkedkernel sous OS X/macOS

Vous avez certainement beaucoup entendu parlé sur les divers forums Hackintosh de l'importance du cache Système. Je vous propose de faire le point sur son fonctionnement et de vous expliquer dans quelles conditions le reconstruire et bien sûr, comment le faire*. Évidemment, il ne s'agit pas de rentrer dans les détails ni de tout savoir sur la question mais juste de présenter quelques notions de base.

De toute manière, il y aurait beaucoup trop à dire sur le sujet et je serais bien incapable de vous en dire plus . N'hésitez pas à commenter ou à me signaler des erreurs ou des oublis.

Cela étant précisé, je vais me concentrer principalement sur les versions récentes d'OS X/macOS et sur les deux principaux bootloaders utilisés à ce jour : Clover et Chameleon/Enoch.

* Si la partie explicative ne vous intéresse pas, téléchargez simplement le script de ce post en PJ .

◉ Les cas où reconstruire le cache est nécessaire :

En fait, il s'agit plutôt de le mettre à jour que de le reconstruire et c'est lorsque l'on modifie le dossier System/Library/Extensions que cela devient important.

Voici les cas où il faut le faire :

■ Lorsque l'on ajoute un ou plusieurs kexts.
■ Lorsque l'on modifie un ou plusieurs kexts (en le patchant "en dur" par exemple comme le font certains logiciels comme ADGPfix).
■ Lorsque l'on supprime un ou plusieurs kexts.

◉ Pourquoi c'est nécessaire ?

Pour comprendre ce qui se passe, il faut savoir qu'OS X/macOS ne s'amuse pas à charger tous les kexts qui se trouvent dans System/Library/Extensions à chaque fois qu'il démarre. Ça prendrait beaucoup de temps et ça n'est pas nécessaire lorsque l'on sait que tous ne sont pas utiles au fonctionnement d'un Mac et à fortiori d'un Hackintosh.

Par exemple, une configuration n'utilisant pas de carte graphique NVIDIA ne va pas charger les kexts nécessaires à son fonctionnement. Tout comme les kexts AMD ne seront pas utilisés sur une configuration qui n'utilise pas ce type de carte graphique.

Pour éviter cela, le système va établir une liste de kexts fréquemment utilisés et va construire un "prelinkedkernel" qui sera chargé par macOS au démarrage. Ainsi, le temps de chargement sera considérablement réduit (je vous la fais très courte parce que c'est un peu plus compliqué que ça mais en gros, c'est ça l'idée ).

Ce prelinkedkernel étant établi sur la base des kexts chargés, il est donc essentiel que lorsque l'on modifie le dossier System/Library/Extensions, les changements soient pris en compte au prochain démarrage. Sans quoi, et comme le système continuera d'utiliser un ancien prelinkedkernel, ils ne seront pas pris en compte. Ou pas complétement.

◉ Je n'utilise que le dossier CLOVER/kexts ou Extra/Extensions. Suis-je concerné ?

En un mot : Non

Dans les deux cas, les kexts placés dans ces endroits ne sont pas pris en compte par le prelinkedkernel. C'est le bootloader qui s'occupera de les charger lors du démarrage et ils viendront "s'ajouter" aux kexts du prelinkedkernel.

En d'autres termes, reconstruire le cache Système ne sert à rien dans ces cas-là.

◉ Qu'en est-t-il des permissions ?

OS X/macOS étant un UNIX, la notion de droits/permissions est essentielle. Pour faire court et simple et dans le cas qui nous concerne, les kexts placés dans les dossiers System/Library/Extensions et Library/Extensions doivent impérativement être "possédés" par le Système et plus précisément par l'utilisateur root (le super utilisateur qui a absolument tous les droits).

Dès lors, il est obligatoire de s'assurer que ces kexts disposent des bons droits et des bonnes autorisations sans quoi le Système refusera de les charger. C'est à ça que servent les utilitaires comme Google: Kext Wizard ou Google: Kext Utility et c'est pourquoi on ne peut pas se contenter de copier/coller des kexts dans ces dossiers.

À noter que :

■ Le dossier Extra/Extensions utilisé parfois par Chameleon/Enoch ne déroge pas à cette règle.

■ Le dossier CLOVER/kexts (et tous ses sous-dossiers) n'est pas soumis à cette obligation.

En effet, la notion de droits/permissions ne s'applique qu'aux volumes HFS+ sous OS X/macOS et comme la partition EFI est un volume FAT32, elle n'est pas concernée. En clair, il n'y a pas besoin de s'occuper des permissions ni de reconstruire le cache lorsque l'on utilise uniquement le dossier EFI/CLOVER.

◉ Comment reconstruire le cache manuellement ?

En principe, vous n'aurez pas à le faire grâce aux utilitaires cités plus haut mais si vous voulez faire ça "proprement" et savoir ce qui se passe réellement, tapez ceci et validez après chaque ligne puis redémarrez :

Code

sudo chmod -R 755 /Library/Extensions
sudo chown -R 0:0 /Library/Extensions
sudo chmod -R 755 /System/Library/Extensions
sudo chown -R 0:0 /System/Library/Extensions
sudo touch /System/Library/Extensions
sudo kextcache -Boot -U /

Pour macOS Big Sur (et suivants) :

Code

sudo chmod -Rf 755 /Library/Extensions
sudo chown -Rf 0:0 /Library/Extensions
sudo touch -f /Library/Extensions
sudo kextcache -i /
sudo kcditto

Vous pouvez également utiliser ce script tout fait.

◉ BONUS - Vérifier/Réparer les permissions sous OS X 10.11 El Capitan :

Vous l'avez peut-être remarqué, l'Utilitaire de disque d'El Capitan ne propose plus de réparer les permissions du disque système.

Apple considère que ce n'est plus nécessaire. C'est peut-être vrai dans le cadre de l'utilisation normale d'un Mac (encore que…) mais sur un Hackintosh, ça peut être utile voire nécessaire dès que le SIP est désactivé et que l'on commence à jouer un peu avec le dossier Système.

Et comme l'ancienne commande terminal

Code

diskutil repairPermissions /

ne fonctionne plus non plus, on pourrait croire que c'est désormais impossible.

Fort heureusement, ce n'est pas le cas !

Simplement, la commande a changé et la fonction existe toujours.

La commande pour vérifier les permissions est la suivante :

Code

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

Et pour les réparer :

Code

sudo /usr/libexec/repair_packages --repair --standard-pkgs /

Si vous souhaitez vérifier/réparer les permissions d'un autre volume que celui du disque de démarrage, il faut adapter comme ceci (si le nom du volume comporte des espaces, pensez à le mettre entre ""):

Code

sudo /usr/libexec/repair_packages --verify --standard-pkgs /Volumes/"nom du volume à vérifier ou réparer"

Ceci étant dit, ne croyez pas que réparer les permissions du disque est la solution à tous les problèmes. Ce n'était pas le cas avec les versions précédentes d'OS X et ça ne l'est toujours pas.

Gardez aussi à l'esprit que cette commande ne reconstruit pas le cache Système et que quoiqu'il arrive, il faudra toujours le faire lorsque c'est nécessaire comme par exemple après l'ajout/modification d'un ou plusieurs kexts dans le dossier /Système/Bibliothèque/Extensions !

Fichier(s) joint(s)

 system_caches_rebuild.command.zip ( 720 octets ) Nombre de téléchargements : 47
 system_caches_rebuild.command_BS.command.zip ( 1009 octets ) Nombre de téléchargements : 2

 

[Patrice Broussea...]

Également possible via cet utilitaire: https://www.firewolf.science/2015/07/repair...sions-v2-0-cli/

Aussi intéressant: http://www.firewolf.science/2015/10/kcpm-u...g-sip-and-more/

Ce message a été modifié par Patrice Brousseau - 10 Nov 2015, 02:43.

[polyzargone]

Également possible via cet utilitaire: https://www.firewolf.science/2015/07/repair...sions-v2-0-cli/

Aussi intéressant: http://www.firewolf.science/2015/10/kcpm-u...g-sip-and-more/

Le second lien me semble en effet très intéressant et bien plus complet que le premier ! Ça pourrait régler le problème de l'installation sous Ozmosis si le SIP peut être désactivé en NVRAM. À essayer …

Merci pour l'info