[Hackintosh Coffee Lake] Gigabyte Z370 HD3P - Intel Core i7-8700K - 16 Go RAM - Radeon RX 570 - macOS/Windows - avec OpenCore, Retex/Guide complet Hackintosh avec OpenCore et carte mère Z370 HD3P

[MaxPoska]

Update au 28/09/2021:

Installation de la mise à jour macOS Big Sur 11.6 (20G165).



OpenCore en version 0.7.3
AppleALC.kext en version 1.6.4
IntelMausi.kext en version 1.0.7
Lilu.kext en version 1.5.6
NVMeFix.kext en version 1.0.9
VirtualSMC.kext (et plugins) en version 1.2.7
WhateverGreen.kext en version 1.5.3

R.A.S

Ce message a été modifié par MaxPoska - 28 Sep 2021, 20:37.

[MaxPoska]

Update au 12/10/2021:

Mise à jour d'OpenCore en version 0.7.4

- Update des fichiers:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:



Ajout d'une propriété "Comment" dans la section UEFI --> Drivers pour chaque driver



- Update des kexts :

AppleALC.kext en version 1.6.5
WhateverGreen.kext en version 1.5.4

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-074-2021-10-04
maxime@iMHackdeMaxime ~ %

R.A.S

[MaxPoska]

Update au 29/10/2021:

Installation de la mise à jour macOS Big Sur 11.6.1 (20G224).



OpenCore en version 0.7.4
AppleALC.kext en version 1.6.5
IntelMausi.kext en version 1.0.7
Lilu.kext en version 1.5.6
NVMeFix.kext en version 1.0.9
VirtualSMC.kext (et plugins) en version 1.2.7
WhateverGreen.kext en version 1.5.4

R.A.S

Pour l'instant, je ne prévois pas d'installer macOS Monterey (comme d'hab j'attends quelques mois avant d'installer une version majeur).
Par contre, je vais probablement l'installer sur un disque dur de test

[MaxPoska]

Update au 11/11/2021:

Mise à jour d'OpenCore en version 0.7.5

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi et HfsPlus.efi (récupéré depuis OCBinaryData pour ce dernier)

- Modification du config.plist:




Ajout du paramètre "ResizeAppleGpuBars" dans la section "Booter" --> "Quirks"
Ajout du paramètre "ResizeGpuBars" dans la section "UEFI" --> "Quirks"

Je laisse la valeur de ces 2 paramètres sur "-1" dans mon config.plist comme dans le sample pour désactiver ces 2 nouveaux paramètres (processeur et carte graphique non compatible de toute façon avec le Resize Bar)

- Update des Kexts

AppleALC.kext en version 1.6.6
Lilu.kext en version 1.5.7
WhateverGreen.kext en version 1.5.5

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-075-2021-11-02
maxime@iMHackdeMaxime ~ %

R.A.S

[tinkar]

Bravo pour ce retour d'expérience extrêmement bien détaillé ! Cela donne envie d'essayer.

[MaxPoska]

Bravo pour ce retour d'expérience extrêmement bien détaillé ! Cela donne envie d'essayer.

Merci

Update au 29/12/2021:

Installation de la mise à jour macOS Big Sur 11.6.2 (20G314).



Mise à jour d'OpenCore en version 0.7.6

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout des paramètres "ReconnectGraphicsOnConnect" et "UIScale" dans la section "UEFI" --> "Output"
Ajout du paramètre "EnableVmx" dans la section "UEFI" --> "Quirks"

Je laisse les valeurs par défaut qui sont dans le sample dans mon propre config.plist pour ces nouveaux paramètres.



Paramètres à supprimer:

Du fait de l'ajout du paramètre "UIScale" dans la section "UEFI" --> "Output", les paramètres suivants sont à supprimer du config.plist:

Suppression du paramètre "UIScale" dans la section "NVRAM" --> "Add" --> "4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14"
Suppression du paramètre "0" avec la valeur "UIScale" dans la section "NVRAM" --> "Delete" --> "4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-076-2021-12-06
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.6.7
Lilu.kext en version 1.5.8
VirtualSMC.kext (et plugins) en version 1.2.8

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 29 Dec 2021, 18:26.

[MaxPoska]

Update au 30/01/2022:

Installation de la mise à jour macOS Big Sur 11.6.3 (20G415).



Mise à jour d'OpenCore en version 0.7.7

Pour cette version, et pour ce qui nous intéresse ici, il y a beaucoup de changement concernant la gestion de l'audio dans le menu de boot d'OpenCore (attention, je parle bien de l'audio dans le boot géré grâce au driver "AudioDxe.efi" et qui sert à avoir, par exemple, le petit "gong" au démarrage. Rien à voir donc avec l'audio au niveau du système macOS (qui lui est géré par le Kext "AppleALC.kext")).

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout du paramètre "SystemAudioVolumeDB" dans la section "NVRAM" --> "Add" --> "7C436110-AB2A-4BBB-A880-FE41995C9F82"
Ajout des paramètres "PointerPollMask", "PointerPollMax", "PointerPollMin" dans la section "UEFI" --> "AppleInput"
Ajout des paramètres "AudioOutMask", "DisconnectHda", "MaximumGain", "MinimumAssistGain", "MinimumAudibleGain" dans la section "UEFI" --> "Audio"

Je laisse les valeurs par défaut qui sont dans le sample dans mon propre config.plist pour ces nouveaux paramètres.

Le paramètre "AudioOutMask" vient remplacer le paramètre "AudioOut" pour définir la sortie audio.
On avait "0" sur "AudioOut" que l'on remplace par "1" pour le paramètre "AudioOutMask".
J'ai bien toujours le "gong" au démarrage.

Paramètres à supprimer:

Suppression des paramètres "AudioOut" (qui est donc remplacé par "AudioOutMask"), "MinimumVolume", "VolumeAmplifier" (dont les fonctions sont remplacés par les différents paramètres que l'on a ajoutés) dans la section "UEFI" --> "Audio"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-077-2022-01-10
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.6.8
Lilu.kext en version 1.5.9
WhateverGreen en version 1.5.6

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 31 Jan 2022, 19:51.

[MaxPoska]

Update au 12/02/2022:

Mise à jour d'OpenCore en version 0.7.8

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètre à supprimer:

Suppression du paramètre "SystemAudioVolumeDB" dans la section "NVRAM" --> "Add" --> "7C436110-AB2A-4BBB-A880-FE41995C9F82"

(Paramètre qui avait été ajouté dans la 0.7.7)

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-078-2022-02-07
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.6.9
Lilu.kext en version 1.6.0
WhateverGreen en version 1.5.7

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 12 Feb 2022, 23:46.

[MaxPoska]

Update au 20/02/2022:

Il y a quelques jours, j'ai fait l'installation de la mise à jour de macOS Big Sur 11.6.4 (20G417).



R.A.S

Sur mon disque dur de test, j'ai installé macOS Monterey.
Je l'ai lancé en mode "mise à jour" depuis macOS Big Sur comme sur un vrai Mac.

Aucun problème lors de de cette mise à jour avec OpenCore 0.7.8

(Pour l'instant, je reste encore avec macOS Big Sur sur mon disque principal)

Ce message a été modifié par MaxPoska - 20 Feb 2022, 22:09.

[MaxPoska]

Update au 13/03/2022:

Mise à jour d'OpenCore en version 0.7.9

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout du paramètre "Strategy" dans la section "Kernel" --> "Block"
Ajout du paramètre "LogModules" dans la section "Misc" --> "Debug"

Je reprends les valeurs par défaut du sample dans mon propre config.plist pour ces 2 paramètres.

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-079-2022-03-07
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.0
WhateverGreen en version 1.5.8
VirtualSMC.kext (et plugins) en version 1.2.9

R.A.S suite à ces updates

[MaxPoska]

Update au 27/03/2022:

Il y a quelques jours, j'ai fait l'installation de la mise à jour de macOS Big Sur 11.6.5 (20G527).



R.A.S

[MaxPoska]

Update au 23/04/2022:

Mise à jour d'OpenCore en version 0.8.0

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout du paramètre "CustomPciSerialDevice" dans la section "Kernel" --> "Quirks"
Ajout du paramètre "ForceAquantiaEthernet" dans la section "Kernel" --> "Quirks"

Ajout du paramètre "Serial" en tant que "paramètre chapeau" (dictionnaire) dans la section "Misc"
Ajout du paramètre "Init" dans la section "Misc" --> "Serial"
Ajout du paramètre "Override" dans la section "Misc" --> "Serial"

Pour l’ensemble de ces nouveaux paramètres, je reprends les valeurs par défaut du sample dans mon propre config.plist.

Paramètre à supprimer:

Suppression du paramètre "SerialInit" dans la section "Misc" --> "Debug"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-080-2022-04-18
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.1

R.A.S suite à ces updates

-------

A noter que depuis 3 mois, il y a une nouvelle version de l'outil OCConfigCompare qui dispose d'une nouveauté fort appréciable.
Pour rappel, cet outil permet de faire la comparaison entre son config.plist et le sample.plist d'une nouvelle version d'OpenCore afin d'en détecter les différences et faire l'ajout/suppression de paramètres plus facilement lors des mises à jour d'OpenCore.

Cette nouvelle version améliore la visibilité des résultats de la comparaison en ne prenant pas en compte certaines sections du config.plist qui sont non pertinentes dans le paramétrage par défaut de l'outil (grâce à la commande "Key Hide Prefixes")



Il en ressort un résultat de comparaison plus "épuré" et pertinent



-------

Ce message a été modifié par MaxPoska - 23 Apr 2022, 22:59.

[MaxPoska]

Update au 17/05/2022:

Installation de la mise à jour macOS Big Sur 11.6.6 (20G624).



R.A.S

[MaxPoska]

Update au 29/06/2022:

Installation de la mise à jour macOS Big Sur 11.6.7 (20G630).



Mise à jour d'OpenCore en version 0.8.1

Une des nouveautés qui va nous impacter avec cette version est que dorénavant, la fonction de "Reset Nvram" (disponible comme entrée dans le menu de boot d'OpenCore) n'est plus inclus dans OpenCore en lui même mais est géré par un driver.
Il y a également un second nouveau driver qui ajoute une entrée dans le menu de boot d'OpenCore permettant d'avoir un raccourci pour activer ou désactiver le SIP (System Integrity Protection): ToggleSipEntry.efi
Je ne vais pas utiliser ce dernier driver donc je ne l'ajoute pas pour ma part.


- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi et ajout d'un nouveau driver ResetNvramEntry.efi

- Modification du config.plist:

Paramètres à ajouter:

Afin de pouvoir exploiter le nouveau driver "ResetNvramEntry.efi" il faut que celui-ci, au même titre que les autres drivers, soit déclaré (et activé) dans le config.plist

Ajout des différents paramètres pour gérer ce driver dans "UEFI" --> "Drivers"



(Il faudra également ajouter les infos pour "ToggleSipEntry.efi" si vous souhaitez l'utiliser)

Paramètres à supprimer:

Suppression des paramètres "AllowNvramReset" et "AllowToggleSip" qui sont dans la section "Misc" --> "Security" dont les fonctions sont gérés par les nouveaux drivers

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-081-2022-06-06
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.2
WhateverGreen en version 1.5.9

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 29 Jun 2022, 23:11.

[MaxPoska]

Update au 07/07/2022:

Mise à jour d'OpenCore en version 0.8.2

Cette version apporte surtout une meilleur compatibilité avec macOS Ventura.
La plupart des kexts sont également mis à jour à cette occasion.

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Aucune modification à faire dans le config.plist

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-082-2022-07-04
maxime@iMHackdeMaxime ~ %

- Update des kexts:

VirtualSMC.kext (et plugins) en version 1.3.0
AppleALC.kext en version 1.7.3
Lilu.kext en version 1.6.1
WhateverGreen en version 1.6.0
NVMeFix.kext en version 1.1.0

R.A.S suite à ces updates

[MaxPoska]

Update au 21/07/2022:

Installation de la mise à jour macOS Big Sur 11.6.8 (20G730).




R.A.S

Probablement ma dernière mise à jour de Big Sur sur ce hack. Il va être temps d'installer macOS Monterey sur mon disque principal

[MaxPoska]

Update au 02/08/2022:

Mise à jour d'OpenCore en version 0.8.3

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Paramètres à ajouter:

Pour chaque driver présent dans "UEFI" --> "Drivers", il y a un paramètre supplémentaire à ajouter: "LoadEarly"
Je laisse la valeur "False" par défaut pour ce paramètre pour tous mes drivers.

Paramètre à supprimer:

Suppression du paramètre "LegacyEnable" dans la section "NVRAM"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-083-2022-08-01
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.4
Lilu.kext en version 1.6.2
WhateverGreen en version 1.6.1

R.A.S suite à ces updates

[MaxPoska]

Update au 10/08/2022:

Mise à jour vers macOS Monterey

----------
----------

Sommaire:

- Prérequis
- Mode mise à jour ou clean install ?
- Création d'une clé USB d'installation
- Installation de macOS Monterey depuis la clé USB
- Utilisation de ProperTree sur Monterey
- Résoudre le problème d’appairage Bluetooth entre macOS et Windows
- Partage de mon EFI basé sur OpenCore 0.8.3

----------
----------

- Prérequis

Avant de faire une mise à jour majeur de macOS, il est important d’avoir OpenCore et les Kexts que l’on utilisent qui soient eux-mêmes à jour.
En effet, la plupart du temps, lors d'une nouvelle version majeure, les bootloaders et/ou kexts ont besoin de faire quelques ajustements pour prendre en charge la nouvelle version de macOS.

Si je regarde les changelogs d'OpenCore, on peut remarquer que macOS Monterey a commencé à être prit en charge à partir de la version 0.7.1 et d'autres ajustements ont été réalisés sur la version 0.7.4.

Pour la mise à jour des Kexts, il suffit d'aller télécharger les dernières versions (liens des Kexts utilisés sur la config dans le post 1 dans la rubrique "Liens Utiles").

Pour la mise à jour d'OpenCore, outre le fait de remplacer les fichiers par la nouvelle version, il y a une attention particulière à porter sur le config.plist qu'il faut bien mettre à jour (voir "Gérer les mises à jour d'OpenCore" de mon retex dans le post 5)
En effet, il est important d’ajouter ou de retirer les paramètres qui sont ajoutés ou supprimés du config.plist de la nouvelle version d’OpenCore par rapport à celle que l’on utilise.
Pour cela, et comme je le décris dans mon retex, on va utiliser l'utilitaire OCConfigCompare pour comparer notre config.plist avec le sample.plist et repérer ainsi les changements.

A titre d’exemple, voici ce que donne une comparaison d’un config.plist de la version 0.7.3 d’OpenCore (qui était la version que je partageais dans ce retex) avec le sample.plist de la dernière version 0.8.3.



On voit qu'il y a eu quelques ajouts et suppressions et c'est un travail qui peut s'avérer plus ou moins long si vous n'avez pas suivi les mises à jour d'OpenCore au fur et à mesure.
Une fois les ajustements faits, pensez à bien vérifier votre config.plist à l’aide de l’utilitaire ocvalidate de la nouvelle version afin de s’assurer que son config.plist est bien conforme, qu’il ne manque pas de paramètres et qu’il n’y a pas d’incohérence.

Encore une fois, vous trouverez plus de détails sur la procédure dans la partie "Gérer les mises à jour d'OpenCore" de mon retex dans le post 5

Je vous conseille également de vérifier dans le fichier pdf de configuration d’OpenCore ou, plus simplement, dans le guide de Dortania, s’il n’y a pas des paramètres à ajuster qui seraient spécifique à macOS Monterey (spoiler alert: rien n’est à ajuster en ce qui concerne notre configuration qui soit spécifique à Monterey )

Pour ma part, ayant suivi les différentes mises à jour successive d’OpenCore, je suis déjà sur la dernière version en date (0.8.3).
J’ai également toutes les dernières mises à jour des kexts.
Donc mon dossier EFI était déjà prêt pour macOS Monterey

- Mode mise à jour ou clean install ?

A partir du moment où l'on a bien respecté les prérequis sur la mise à jour d'OpenCore et de ses kexts, la mise à jour de macOS peut être effectuée en mode "mise à jour" depuis les "Préférences système" comme sur un vrai Mac !

J'ai pu faire le test et tout s'est bien déroulé. Je n'ai rien eu à faire de particulier et je suis passé de macOS Big Sur à macOS Monterey en quelques minutes sans rien faire de particulier et après quelques reboot.
J'ai quand même au préalable déconnecté le SSD où était installé Windows mais c'est plus par précaution que par obligation.

Cela étant dit, pour ma part, je préfère partir sur une clean install (donc une réinstallation complète du système) lors d’une mise à jour majeur.
Ça me permet de repartir sur un système propre. Rien à voir avec le hackintosh donc, c’est juste une question d’habitude (je fais la même chose sur mon MacBook Pro).


- Création d'une clé USB d'installation

Qui dit clean install, dit préparation d’une nouvelle clé USB de boot

De la même manière que l’on avait créé une clé USB de boot pour macOS Big Sur, on va utiliser la commande "createinstallmedia" pour créer une nouvelle clé USB de boot pour macOS Monterey (voir les explications dans le post 1 dans la rubrique "Création de la clé USB")

La commande à taper dans le Terminal pour macOS Monterey est la suivante (en partant du principe que votre installateur de Monterey se trouve dans le dossier "Applications" et que la clé USB se nomme "MyVolume"):

Code

sudo /Applications/Install\ macOS\ Monterey.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume

Ensuite, pour rendre la clé compatible hackintosh, il suffit de recopier le dossier "EFI" qui est présent dans la partition du disque où macOS Big Sur est installé (toujours en à l'aide de l’utilitaire "MountEFI" pour monter la partition EFI) dans la partition "EFI" de la clé USB.
En effet, tout le paramétrage a été fait précédemment, il suffit de reprendre le fruit de nos travaux

Copier bien le dossier "EFI" en lui même avec ses sous dossiers



Vous aurez peut être remarqué qu’il y a un dossier supplémentaire dans notre dossier "EFI" comparé à la clé USB d’installation que nous avions créée pour macOS Big Sur.

En effet, en plus des dossiers "BOOT" et "OC" d’OpenCore, il y a un dossier "APPLE" qui contient un sous dossier "FIRMWARE" qui lui même contient un fichier.
C’est un fichier qui est automatiquement créé lors de l’installation de macOS et qui sert à la mise à jour des firmwares des vrais Mac.
Vous n’avez pas à vous en soucier, ce n’est pas utiliser pour notre hackintosh et vous pouvez, au choix laisser ce dossier "APPLE" ou le supprimer sur la clé USB d’installation.
On en parle ici sur le guide de Dortania.
Pour ma part, je l'ai supprimé et conservé uniquement les dossiers "BOOT" et "OC" (histoire de se débarrasser du superflu )

Ensuite, j’apporte une petite modification sur le config.plist de la clé USB pour être en mode verbose (utile pour le déboguage s'il y a un a problème lors de l’installation).
Pour ce faire, j’ajoute le paramètre "-v" dans la section "NVRAM --> Add --> 7C436110-AB2A-4BBB-A880-FE41995C9F82" au niveau du paramètre "boot-args"



- Installation de macOS Monterey depuis la clé USB

L'installation de macOS Monterey se déroule exactement de la même manière que pour macOS Big Sur (voir la partie "Installation de macOS" dans le post 3 du Retex)
Prenez bien soin de régler la priorité de démarrage pour que la clé USB soit en premier dans l'ordre de Boot.
Personnellement, je préfère également déconnecter tous les disques durs brancher et ne garder que le SSD sur lequel on va installer macOS de brancher pour ne pas que l'installateur de macOS installe des choses la où il ne devrait pas (encore une fois, c'est plus une précaution qu'une obligation).

Ensuite, l'installation se déroule normalement: On sélectionne "Install macOS Monterey" dans le menu de boot, on arrive sur le menu d'installation, on formate/choisis le disque sur lequel on veut installer son système puis on patiente

Après quelques reboots, l'installation de macOS est terminé et on arrive sur l'écran de configuration (la où l'on créé son compte local, définis son mot de passe ect).
Pour finir, on arrive enfin sur le bureau de macOS Monterey .

Ensuite, comme expliqué dans le Retex, il suffit de monter la partition "EFI" de la clé USB pour récupérer le dossier "EFI" et le copier pour le coller dans la partition "EFI" du SSD où est installé macOS Monterey.
Dès lors, on peut démarrer sans clé USB (et au redémarrage, on sélectionne "OpenCore" dans le BIOS en 1er dans l'ordre de boot)

Enfin, on retire le mode verbose.
Pour ce faire, on édite notre config.plist pour retirer le "-v" dans la section "NVRAM --> Add --> 7C436110-AB2A-4BBB-A880-FE41995C9F82" au niveau du paramètre "boot-args" toujours à l'aide de "ProperTree".

En parlant de ProperTree, je me suis rendu compte qu'il y avait une petite subtilité pour pouvoir l'utiliser sur macOS Monterey.
On voit ça juste en dessous

- Utilisation de ProperTree sur Monterey

Sur macOS Monterey, il semble qu'il y ait un problème dans le composant Python inclus dans le système qui gère les interfaces graphiques (brique "tk").
Si on créé l'application ProperTree grâce au script, en sélectionnant simplement "/usr/bin/env python3" comme je l'indique dans la partie "Paramétrage du config.plist" à la fin du post 1 du Retex, on se retrouvera avec une application qui sera inutilisable car l'interface sera entièrement noir.

Pour contourner le problème, il faut installer la dernière version de Python 3 (si vous avez utilisé MountEFI juste après l'installation pour accéder aux partitions "EFI", vous devriez déjà avoir installé Python 3 donc vous n'avez pas à le refaire )

Ensuite, lorsque l'on utilisera le script "buildapp-select.command" pour créer l'application, il faut sélectionner l'option "/usr/local/bin/python3 3.10.6 - tk 8.6" (et non pas "/usr/bin/env python3 comme pour Big Sur)



- Résoudre le problème d’appairage Bluetooth entre macOS et Windows

Après ma nouvelle installation de macOS Monterey, je me suis rendu compte d’un problème dans mon utilisation du dual boot avec Windows, en particulier avec mes périphériques Bluetooth (clavier et souris).

En effet, lorsque je bootais sur Windows, ma Magic Mouse et mon Magic Keyboard n’était plus appairer. Je devais les ré-appairer avec Windows pour que mes périphériques Bluetooth fonctionnent à nouveau.
Le problème, est que lorsque je retournais sur macOS, cette fois si c’était macOS qui perdait l’appairage et je devais donc ré-appairer mon clavier et ma souris avec macOS. Et ceci se produisait à chaque boot d’un OS à l’autre.

Bien que je ne boot pas souvent sur Windows, il se trouve qu’en ce moment, je dois pas mal le faire pour utiliser un programme qui n’existe pas sur macOS. Ce problème de perte d’appairage m’a donc vite agacer et après une recherche, j’ai trouvé une explication et une solution rapide.

J’ai donc trouvé la solution ici

Le problème réside donc dans le fait que lors d’un appairage entre un périphérique Bluetooth et un OS, une "clé de connexion" se génère et est stockée par le système. Cette clé est différente à chaque appairage et c’est pour cela que je perds la connexion à chaque appairage entre macOS et Windows: la clé de connexion est différente sur chacun des 2 OS.

La solution est donc simple: il suffit d’avoir la même clé de connexion sur les 2 systèmes pour que les périphériques Bluetooth puissent fonctionner sur les 2 OS sans avoir besoin de les ré-appairer à chaque fois
Apparemment, sur les vrai Mac, c’est BootCamp qui se charge de faire cette synchronisation de clés entre les 2 systèmes.
Bien que j’ai BootCamp installé sur ma partition Windows, je ne sais pas si cette synchronisation ne se fait pas car c’est un hackintosh et non un vrai Mac ou que j’utilise une ancienne version de BootCamp ou pour une autre raison.

Quoi qu’il en soit, pour résoudre le problème, j’ai donc suivi les étapes décrites par l’auteur du fil Reddit, à savoir:

1. Démarrer sur Windows et appairer mon clavier et ma souris à Windows
2. Redémarrer sur macOS et appairer à nouveau mes périphériques à macOS
3. Ouvrir l’application "Trousseau d’accès" sur le Mac
4. Rechercher les entrées qui s’appellent "MobileBluetooth":
Il devrait y avoir 1 entrée "MobileBluetooth" pour chaque appareil appairé.
Pour savoir quelles sont les entrées Bluetooth qui correspondent à quelle périphérique, pour chaque ligne "MobileBluetooth", vous avez une information qui est nommée "Compte".
Il s’agit de l’identifiant unique de notre périphérique (l’adresse MAC).
Vous pouvez savoir à quelle périphérique appartient chaque adresse MAC en allant dans l’application "Informations systèmes" au niveau de la rubrique "Matériel --> Bluetooth"



Dans mon cas, on sait que:

- Le clavier correspond à l’adresse MAC commençant par 70:F0:87
- La souris correspond à l’adresse MAC commençant par 48:4B:AA
- La carte Bluetooth en elle même a également une adresse MAC qui commence par 88:63:DF (on peut le noter car ça nous servira pour s’y retrouver tout à l’heure dans Windows)

Notez ces informations quelques part sur un bout de papier ou dans un fichier texte dans TextEdit par exemple.

5. Double cliquer sur chaque entrée mobile Bluetooth qui nous intéresse et cocher la case "Afficher le mot de passe" (taper votre nom et votre mot de passe pour afficher la donnée)
En réalité ce n’est pas un mot de passe qui va s’afficher mais des données sous forme XML.

6. Cliquer dans la zone de texte, appuyer sur les touches "Command + A" pour tout sélectionner et copier coller le contenu dans un fichier texte pour récupérer tout le contenu de l’XML. Répéter l’opération pour chaque périphérique (clavier et souris dans mon cas).



Ce qui va nous intéresser dans ce xml c’est la balise "LinkKey" qui contient la fameuse clé de connexion que l’on va devoir recopier sur Windows.



7. Copier votre fichier texte dans lequel vous avez noté toutes les infos sur une clé USB ou à un endroit accessible depuis votre partition Windows et redémarrer sur Windows.
Assurez vous d’avoir un clavier et une souris en USB à utiliser sous Windows le temps de faire la manip (puisque le clavier et la souris Bluetooth ne seront plus appairer).

8. Sur Windows, nous allons avoir besoin d’un petit utilitaire pour éditer la base de registre. Pour cela, télécharger PSTools
9. Dézipper le fichier zip téléchargé. L’utilitaire dont a besoin est "psexec.exe". Je vous conseil de déplacer l’utilitaire "Psexec.exe" qui est dans le répertoire "PStools" que l’on a téléchargé, à la racine de votre disque (C:) afin de pouvoir y accéder plus facilement en ligne de commande.
10. Exécuter l’application "Invite de commandes" en tant qu’administrateur. Pour ce faire, taper "cmd" dans la barre de recherche et positionnez vous sur "invite de commandes" et enfin cliquer sur "Exécuter en tant qu’administrateur"



11. Dans la fenêtre qui s’ouvre taper "cd c:/"  (ou le chemin complet où vous avez mis l’utilitaire psexec.exe) puis taper la commande

Code

psexec -s -i regedit

12. Une fenêtre d’acceptation du contrat va s’ouvrir, cliquer sur "Agree"



13. L’éditeur de registre va alors s’ouvrir.
Dans la partie gauche, aller dans le répertoire:

Code

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\Adresse_MAC_de-votre-carte (dans mon cas 8863df….)

14. Dans la partie droite, c’est ici que l’on retrouve la clé de connexion (dans la colonne "Données") associé à l’adresse MAC (que l’on repère dans la colonne "Nom") correspondant au clavier et à la souris.
On voit bien que les clés de connexion sont différentes entre ce qu’il y a sur macOS et ce qu’il y a sur Windows.



15. Il faut donc que l’on modifie ce qu’il y a dans la colonne "Données" afin d’avoir la même clé de connexion que ce qu’il y a sur macOS
Pour ce faire, double cliquer sur l’adresse MAC dans la colonne "nom" du périphérique pour lequel on souhaite modifier la clé de connexion.
Une fenêtre "modification de la valeur binaire" va alors s’afficher.
Effacer la clé existante et recopier la clé qui est utiliser sur Macos (pas besoin de mettre les tirets) puis cliquer sur "Ok"





16. Fini Maintenant que l'on a la même clé de paramétré sur Windows et macOS, plus de problème de dés-appairage

- Partage de mon EFI basé sur OpenCore 0.8.3

Je vous mets à disposition mon dossier "EFI" pour la Z370 HD3P de la clé USB d'installation basé sur OpenCore 0.8.3: https://www.dropbox.com/s/bj4kkv1l5hrbmks/E...70HD3P.zip?dl=0

ATTENTION: Il y a quelques réglages à faire dans le config.plist avant d'utiliser ce dossier "EFI":

- Si vous n'utilisez pas le BIOS modifié par Gigabyte pour avoir l'option "CFG-Lock" de disponible dans le BIOS (voir le détails dans le post 3 du retex) vous devrez alors passer le paramètre "AppleXcpmCfgLock" à "True" dans le config.plist dans la section "Kernel --> Quirks"
- Le config.plist mis en partage est vierge de numéros de série. Vous devrez générer les vôtres à l'aide de l'outil GenSMBIOS et renseigner les paramètres nécessaires dans la section "PlatformInfo"
Vous trouverez plus de détails sur les paramètres à renseigner dans la section "PlatformInfo" ainsi que l'utilisation de GenSMBIOS dans le post 2.
- Le config.plist mis en partage est réglé pour être en mode verbose. Vous pouvez lire la partie "fignolage" du retex dans le post 4 pour savoir comment le retirer en post installation.

-----------

Pour conclure, ma mise à jour vers macOS Monterey s'est passé de manière totalement fluide (sans vraiment de surprise, je sais que ça fonctionne bien depuis plusieurs mois ) et, à part les 2 derniers points remontés, je n'ai rien de particulier à signaler

Ce message a été modifié par MaxPoska - 7 Sep 2022, 22:02.

[MaxPoska]

Update au 18/08/2022:

Installation de la mise à jour macOS Monterey 12.5.1 (21G83).




R.A.S

[MaxPoska]

Update au 07/09/2022:

Mise à jour d'OpenCore en version 0.8.4

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Il n'y a pas de paramètres à retirer ou ajouter

(sauf si vous utilisez les "tools", dans ce cas la, il y a un nouveau paramètre à ajouter: "FullNvramAccess" pour chaque outils utilisé)

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-084-2022-09-05
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.5

R.A.S suite à ces updates

[MaxPoska]

Update au 14/09/2022:

Installation de la mise à jour macOS Monterey 12.6 (21G115).



R.A.S

[MaxPoska]

Update au 08/10/2022:

Mise à jour d'OpenCore en version 0.8.5

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Il n'y a pas de paramètres à retirer ou ajouter

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version  
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-085-2022-10-04
maxime@iMHackdeMaxime ~ %

- Update des kexts:

Pas d'update de Kexts

R.A.S suite à ces updates

[MaxPoska]

Update au 28/10/2022:

Installation de la mise à jour macOS Monterey 12.6.1 (21G217).



R.A.S

[Koni]

Mise à jour de Big Sur 11.7.1 (20G918) ce matin. Un franc succès...

[MaxPoska]

Update au 08/11/2022:

Mise à jour d'OpenCore en version 0.8.6

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout des 3 paramètres suivants dans la section "UEFI" --> "AppleInput" :

- "PointerDwellClickTimeout"
- "PointerDwellDoubleClickTimeout"
- "PointerDwellRadius"

Je reprends les valeurs par défaut du sample dans mon propre config.plist pour ces 3 paramètres.



Paramètre à supprimer:

Aucun

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-086-2022-11-07
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.6


R.A.S suite à ces updates

[MaxPoska]

Je remarque un problème récurrent depuis 3 mois que je suis passé sous macOS Monterey.

J'ai régulièrement un problème de freeze où tout devient lent et quasi inutilisable avec l'apparition de la roue multicolore constamment.
J'attends plusieurs minutes ou je redémarre le hack (quand j'y arrive et si j'ai la patience sinon j'éteins et rallume à la bourrin avec le bouton power ), et la plus de problème.

J'ai constaté ce phénomène le plus souvent quand j'allume l'ordi puis je pars pendant plusieurs minutes/heures et que je reviens.
C'est à ce moment que je constate ces freezes (mais pas tout le temps).

Je ne sais pas à quoi cela est du. Un paramétrage ? un kext qui pose problème ? un problème matériel ? un problème avec Monterey ?
Faudrait que j'investigue un peu mais pour l'instant, flemme

Quoi qu'il en soit, je n'avais jamais eu ce phénomène sous macOS Big Sur.

A suivre...

[tinkar]

J'ai aussi ce problème. sur un de mes hacks. sur l'autre comme je suis en train d'essayer de changer le BIOS (Imac pro 1,1 en MACPro 7.1) je n'avais pas encore remarqué le phénomène. Mais oui, je suis obligé aussi de redémarrer. J'attends une version Ventura 13.1 ou 13.2 (une version plus aboutie que celle présente) pour voir ce que cela donne sur cette version.

[MaxPoska]

Merci pour ton retour tinkar, je me sens moi seul sur ce problème

Il y a quelques temps, j'avais fait des recherches sur internet mais je n'avais rien trouvé de très probant.
A un moment, je me suis demandé si c'était pas un souci de "réveil" de mes disques durs quand ceux ci ne sont pas utilisés pendant une certaine période (car j'avais l'impression quand tout "freezait", qu'il y avait des tentatives d'accès aux disques)
J'avais alors décoché la case "Suspendre dès que possible l'activité des disques durs" dans le menu "Économiseur d'énergie" des "Préférences Système" pour que ceux ci ne soient pas en veille...mais ça n'a rien changé.

J'attends également une version de macOS Ventura plus avancé (au moins la .2 ou .3) avant de mettre à jour vers cet OS pour voir si j'ai toujours ce problème sous Ventura.

Ce message a été modifié par MaxPoska - 27 Nov 2022, 17:48.

[MaxPoska]

Update au 09/12/2022:

Mise à jour d'OpenCore en version 0.8.7

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Paramètre à ajouter:

Ajout du paramètre suivant dans la section "Misc" --> "Boot" :

- "HibernateSkipsPicker"

Je reprends la valeur par défaut du sample dans mon propre config.plist pour ce paramètre.



Paramètre à supprimer:

Aucun

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-087-2022-12-06
maxime@iMHackdeMaxime ~ %

- Update des kexts:

- AppleALC.kext en version 1.7.7
- WhateverGreen.kext en version 1.6.2


R.A.S suite à ces updates

Upgrade matériel:

J'ai profité du black friday pour changer le SSD sur lequel Windows est installé.
J'ai donc remplacé le SSD MX 300 750 Go (en sata) par un SSD WD Black SN770 d'1To (en nvme)



Bien sur, ce modèle est overkill sur ma configuration puisque c'est un SSD PCIe Gen4 alors que la carte mère est limité à du PCIe Gen3.
Le SSD est donc un peu bridé (enfin à relativiser tout de même, on parle quand même de 3000Mo/s en lecture/écriture en PCIe Gen3 qui est déjà trèèèès bien )
Mais bon, c'était un excellent rapport qualité prix au moment de l'achat et qui peut le plus peut le moins .

Mes 2 OS sont maintenant chacun sur 1 SSD performant comme ça il n'y a plus de jaloux et j'ai mes 6 ports SATA utilisable pour mes disques durs

Ce message a été modifié par MaxPoska - 9 Dec 2022, 20:48.

[Aggie26]

Bonjour,

Je rencontre aussi un problème de freeze où tout devient lent et quasi inutilisable après plusieurs heures d'absence, ordi allumé bien entendu.

Je resre intéressé si qqn trouve une solution à l'occasion.