Sagar Hozkatua: un Mac Pro a la bilbaina (OpenCore 1.0.2)
- Autor DeBilbao
- Fecha de inicio
-
- Etiquetas
- hackintosh mac pro sagar hozkatua
Yo creo que es el unknown ese que aparece mucho. Y que la bujía de la bobina bloquea la valvulina del catéter y hace que el cárter gripe la culata. Yo ahí lo dejo. No creo que sea de la sal.
Cosa curiosa. Estoy con el remapeo. Pese a haber incluido en las exclusiones a HS01 y HS02, siguen empeñados en salir.
Ver el archivo adjunto 33727
@Manu1001 ¿cómo llevas este tema?
Esa última captura de pantalla se acerca a lo que debe ser el mapeo de puertos USB. Solo tienes un puerto Internal, en el que aparece correctamente identificado el dispositivo Bluetooth de la Fenvi T-919, que tiene un chipset de Broadcom de la serie 2070, y los demás son USB 3.0, o USB-C o TB.
No sé si es correcto, porque no tengo una lista precisa del hardware que tienes instalado en ese equipo, pero pinta bien.
Aún así, con tantos cambios que has hecho podrías tener la NVRAM en mal estado y yo probaría a borrarla.
Cuando aparezca el selector de OpenCore en la pantalla de arranque, verás una opción "Reset NVRAM"
Púlsala y después inicia de nuevo el equipo. Tendrás que entrar en la BIOS para ajustar los discos de arranque en la sección "Boot", y después recordarle a macOS Monterey cuál es el disco de arranque que debe utilizar.
OpenCore y unas cuantas extensiones del kernel se ha actualizado hoy a la versión 0.7.7, y he actualizado mi carpeta EFI con las actualizaciones tanto del gestor de arranque como de las extensiones de kernel y los recursos de BinaryData.
Actualización a la versión de OpenCore 0.7.7
github.com
Este es el registro de cambios, la mayoría centrados en la mejora de la reproducción de audio en el proceso de arranque
github.com
github.com
github.com
github.com
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias en ambos sentidos, que toca actualizar.
Y las he copiado como siempre, usando PlistEditor, mi editor de archivos plist favorito.
Primero añadimos en NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82
Añadimos también UEFI > AppleInput
Eliminar - ojo, eliminar - estas tres entradas en UEFI > Audio
Y por último, añadir estas 5 entradas a UEFI > Audio
Y volvemos a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.7.7
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
ProperTree.cmd dejó de funcionarme bien con macOS Monterey y presentaba una pantalla en negro, pero pude resolverlo compilando el comando Python y convirtiéndolo en una aplicación, que ahora uso en lugar del script.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados hoy.
La primera prueba la hacemos "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciamos el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB que tan buen resultado da con macOS Monterey.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.7.7, publicado el 10 de enero de 2022.
Y tras arrancar, todo funciona correctamente. Hackintool también se ha actualizado a la versión 3.8.4 y muestra que mis puertos USB 2, USB 3 y USB-C siguen mapeados y los dispositivos que tengo conectados a los mismos operativos.
Actualización a la versión de OpenCore 0.7.7
OpenCore v0.7.7
Release 0.7.7 · acidanthera/OpenCorePkg
v0.7.7 Fixed rare crash caused by register corruption in the entry point Added ProvideCurrentCpuInfo support for Intel Alder Lake Fixed typo in Cpuid1Data recommendations for Intel Rocket Lake and...
github.com
Este es el registro de cambios, la mayoría centrados en la mejora de la reproducción de audio en el proceso de arranque
- Fixed rare crash caused by register corruption in the entry point
- Added ProvideCurrentCpuInfo support for Intel Alder Lake
- Fixed typo in Cpuid1Data recommendations for Intel Rocket Lake and newer
- Updated builtin firmware versions for SMBIOS and the rest
- Updated underlying EDK II package to edk2-stable202111
- Resolved crashes in QEMU with AudioDxe
- Added AudioDxe settings caching (avoids non-needed setup delays)
- Added DisconnectHda quirk to allow UEFI sound on Apple hardware and others
- Added workarounds for bugs in QEMU intel-hda driver to allow UEFI sound in QEMU
- Implemented multi-channel (e.g. bass+main speaker; speakers+headphones) UEFI sound with AudioOutMask
- Fixed AudioDxe startup stalls when Nvidia HDA audio is present
- Resolved AudioDxe disabling sound in Windows on some firmware
- Added pointer polling period tuning in the builtin AppleEvent implementation
- Added pointer device list tuning in the builtin AppleEvent implementation
- Added VREF handling to support UEFI sound on more Apple hardware
- Updated audio output channel detection to support UEFI sound on more Apple hardware
- Added manual GPIO config (use --gpio-setup AudioDxe driver argument for UEFI sound on Apple hardware)
- Switched UEFI audio levels to decibel gain to allow accurate matching of saved macOS volume levels
- Separated settings for minimum audio assist volume and minimum audible volume
OCBinaryData
GitHub - acidanthera/OcBinaryData
Contribute to acidanthera/OcBinaryData development by creating an account on GitHub.
github.com
- Drivers > Solo el archivo HfsPlus.efi
- Resources > Toda las carpetas
RestrictEvents v1.0.6
Release 1.0.6 · acidanthera/RestrictEvents
v1.0.6 Fixed memory view restrictions for MacBookAir and MacBookPro10 not being correctly disabled Disabled The disk you inserted was not readable by this computer message popup Added Content Cach...
github.com
- Fixed memory view restrictions for MacBookAir and MacBookPro10 not being correctly disabled
- Disabled The disk you inserted was not readable by this computer message popup
- Added Content Caching support for systems exposing kern.hv_vmm_present via -revasset
- Lowered OS requirement for -revsbvmm to macOS 11.3
AppleALC v1.6.8
Release 1.6.8 · acidanthera/AppleALC
v1.6.8 Replace patch for 500 Series(0x43C8) PCH HD Audio Added ALC269-VC for Samsung NP540U4E #752 by @majonez Added ALC1220A layout 8 for MSI z490i unify by @viorel78 Added front panel connection...
github.com
v1.6.8
- Replace patch for 500 Series(0x43C8) PCH HD Audio
- Added ALC269-VC for Samsung NP540U4E #752 by @majonez
- Added ALC1220A layout 8 for MSI z490i unify by @viorel78
- Added front panel connections in ALC892 layout 23 for ASRock B365 Pro4 by @TheHackGuy
- Removed redundant 8086:A171 controller patches by @al3xtjames
- Fixed wakeconfigdata for ALC236 LayoutID 36 by @volcbs
- Fixed Combo jack for CX8200 layout-id 80 by @vivzero
- Added ALC897 layout 11 for GIGABYTE Z590M
WhateverGreen v1.5.6
- Fixed deprecated code in unfairgva
LiLu v1.5.8
Release 1.5.8 · acidanthera/Lilu
v1.5.8 Fixed kernel panic on macOS 10.15 and earlier introduced in 1.5.7 Added Alder Lake CPU model support Added shared patcher instance grabbing API
github.com
- Added address slot support for all 64-bit macOS version
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias en ambos sentidos, que toca actualizar.
Y las he copiado como siempre, usando PlistEditor, mi editor de archivos plist favorito.
Primero añadimos en NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82
Añadimos también UEFI > AppleInput
Eliminar - ojo, eliminar - estas tres entradas en UEFI > Audio
Y por último, añadir estas 5 entradas a UEFI > Audio
Y volvemos a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.7.7
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
ProperTree.cmd dejó de funcionarme bien con macOS Monterey y presentaba una pantalla en negro, pero pude resolverlo compilando el comando Python y convirtiéndolo en una aplicación, que ahora uso en lugar del script.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados hoy.
La primera prueba la hacemos "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciamos el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB que tan buen resultado da con macOS Monterey.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.7.7, publicado el 10 de enero de 2022.
Y tras arrancar, todo funciona correctamente. Hackintool también se ha actualizado a la versión 3.8.4 y muestra que mis puertos USB 2, USB 3 y USB-C siguen mapeados y los dispositivos que tengo conectados a los mismos operativos.
Última edición:
Estoy revisando el primer post del hilo, para dejarlo actualizado con la configuración que utilizo ahora mismo, con la última versión de macOS Monterey 12.2, con OpenCore 0.7.7 como gestor de arranque sobre la placa base Z390 Designare.
De momento he revisado la sección de la BIOS, que he actualizado recientemente a una versión F9i modificada que incorpora las últimas correcciones para las vulnerabilidades aplicadas por Gigabyte para los procesadores de Intel.
La versión F9i es la última versión "segura" de Gigabyte para usarla con macOS, y a Enero de 2022, ha desaparecido de su página web, pero he guardado una copia y podéis descargarla desde aquí. En la web oficial están las versiones F9j y F9, pero estas no debemos instalarlas si queremos que funcione bien nuestro equipo con macOS.
Una vez instalada esta versión F9i, podéis instalar una versión especial modificada por el usuario Elias64Fr de los foros de tonymacx86, que la ha modificado para incorporar unos parches posteriores de seguridad que actualizan el microcódigo del procesador a la versión 0xEA. Yo la he instalado y os dejo una copia aquí por si queréis instalarla vosotros también, algo que me parece muy recomendable.
IMPORTANTE: Antes de instalar la versión F9i modificada, es necesario tener instalada la versión F9i oficial.
Yo tengo las dos copiadas en un pendrive de 4GB que tengo inicializado en formato MSDOS (FAT) para que sea compatible con la BIOS. Solo hay que acceder a la sección Q-Flash en la BIOS y elegir cada uno de los archivos. Primero la F9i oficial y en una segunda pasada la F9i modificada por Elias64Fr
Y una vez elegido el archivo, solo hay que avanzar y confirmar el proceso. Recordad que el proceso borra los ajustes, así que conviene tenerlos guardados en un perfil que almacenaremos también en el pendrive. Si queréis utilizar los míos, los he guardado aquí.
He comparado las dos BIOS utilizando el programa UEFITool NE y ahí están las modificaciones al microcódigo. A la izquierda la F9i oficial y a la derecha la F9i modificada.
Aún así, no estamos protegidos al 100%, pues ejecutando el programa Intel Converged Security and Management Engine Version Detection Tool desde Windows, y me indica que mi sistema es vulnerable.
Así que leyendo la documentación del programa, el sistema es vulnerable a alguna de las siguientes vulnerabilidades.
He comparado la BIOS F9i de Elias64Fr con la nueva F9 oficial de Gigabyte, y ambas tienen las mismas cuatro entradas de microcódigo y con el mismo checksum, así que a efectos de seguridad de microcódigo, serían equivalentes.
Toca esperar a que Gigbayte publique alguna actualización posterior y a que Elias64Fr las integre en la que sabemos que funciona.
De momento he revisado la sección de la BIOS, que he actualizado recientemente a una versión F9i modificada que incorpora las últimas correcciones para las vulnerabilidades aplicadas por Gigabyte para los procesadores de Intel.
La versión F9i es la última versión "segura" de Gigabyte para usarla con macOS, y a Enero de 2022, ha desaparecido de su página web, pero he guardado una copia y podéis descargarla desde aquí. En la web oficial están las versiones F9j y F9, pero estas no debemos instalarlas si queremos que funcione bien nuestro equipo con macOS.
Una vez instalada esta versión F9i, podéis instalar una versión especial modificada por el usuario Elias64Fr de los foros de tonymacx86, que la ha modificado para incorporar unos parches posteriores de seguridad que actualizan el microcódigo del procesador a la versión 0xEA. Yo la he instalado y os dejo una copia aquí por si queréis instalarla vosotros también, algo que me parece muy recomendable.
IMPORTANTE: Antes de instalar la versión F9i modificada, es necesario tener instalada la versión F9i oficial.
Yo tengo las dos copiadas en un pendrive de 4GB que tengo inicializado en formato MSDOS (FAT) para que sea compatible con la BIOS. Solo hay que acceder a la sección Q-Flash en la BIOS y elegir cada uno de los archivos. Primero la F9i oficial y en una segunda pasada la F9i modificada por Elias64Fr
Y una vez elegido el archivo, solo hay que avanzar y confirmar el proceso. Recordad que el proceso borra los ajustes, así que conviene tenerlos guardados en un perfil que almacenaremos también en el pendrive. Si queréis utilizar los míos, los he guardado aquí.
He comparado las dos BIOS utilizando el programa UEFITool NE y ahí están las modificaciones al microcódigo. A la izquierda la F9i oficial y a la derecha la F9i modificada.
Aún así, no estamos protegidos al 100%, pues ejecutando el programa Intel Converged Security and Management Engine Version Detection Tool desde Windows, y me indica que mi sistema es vulnerable.
Así que leyendo la documentación del programa, el sistema es vulnerable a alguna de las siguientes vulnerabilidades.
- SA-00086
- SA-00125
- SA-00213
- SA-00241
- SA-00295
- SA-00404
- SA-00391
- SA-00459
He comparado la BIOS F9i de Elias64Fr con la nueva F9 oficial de Gigabyte, y ambas tienen las mismas cuatro entradas de microcódigo y con el mismo checksum, así que a efectos de seguridad de microcódigo, serían equivalentes.
Toca esperar a que Gigbayte publique alguna actualización posterior y a que Elias64Fr las integre en la que sabemos que funciona.
Fiel a su actualización mensual, OpenCore y se ha actualizado hoy a la versión 0.7.8, y ya he actualizado la carpeta EFI que controla el inicio de mi Sagar Hozkatua con macOS Monterey.
Actualización a la versión de OpenCore 0.7.8
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias solo en un sentido, y no he tenido que hacer nada más que eliminar una clave que ya no se debe utilizar.
Y volvemos a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.7.8
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados hoy.
La primera prueba la hacemos "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.7.8, publicado el 07 de febrero de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado.
Actualización a la versión de OpenCore 0.7.8
OpenCore v0.7.8
Release 0.7.8 · acidanthera/OpenCorePkg- Updated ocvalidate to warn about insecure DmgLoading with secure SecureBootModel (already disallowed in runtime)
- Fixed AudioDxe not disabling unused channels after recent updates
- Allow gain to track OS volume on old macOS without SystemAudioVolumeDB
- Fixed crash on no mouse support when verifying password
- Fixed AppleInternal CSR bit being set with ProvideCustomSlide enabled
- Added support for .contentFlavour and .contentDetails files for boot entry protocol entries including OpenLinuxBoot
- Added LINUX_BOOT_ADD_RW flag to OpenLinuxBoot to support e.g. EndeavourOS
- Added flags+= and flags-= arguments to OpenLinuxBoot to simplify setting driver flags if needed
- Fixed OpenLinuxBoot entry name disambiguation when LINUX_BOOT_USE_LATEST flag is clear
- Updated builtin firmware versions for SMBIOS and the rest
- Fixed crash in OpenLinuxBoot with partly (re-)installed Linux distro
- Improved robustness in malformed PE image file parsing
OCBinaryData
GitHub - acidanthera/OcBinaryData- Drivers > Solo el archivo HfsPlus.efi
- Resources > Toda las carpetas
AppleALC v1.6.9
Release 1.6.9 · acidanthera/AppleALC- Added 0x100003 revision for ALCS1220A
- Updated pinconfig ALC897 layout-id 12 by @Sergey-Galan
- Replace 200 Series PCH HD Audio 0xA2F0 controller patch
- Update 0xA2F0 controller patch to fix HDMI audio by @Core-i99
- Improved compatibility of alc-verb with Linux hda-verb
- Reduce input gain for mics for layout 20 ALC230
- Update Pin Config for layout 16 ALC1220
- Added ALC294 layout-id 44 for ASUS UX534FAC by @narcyzzo
- Added ALC1220A Layout 13 for Asus ProArt Z690-Creator WiFi by @CaseySJ
WhateverGreen v1.5.7
Release 1.5.7 · acidanthera/WhateverGreen- Fixed maximum backlight level on Ice Lake IGPUs
LiLu v1.6.0
Release 1.6.0 · acidanthera/Lilu- Dropped internal shared patcher instance grabbing API
CupTscSync v1.0.6 (LiLu Plug-in)
Release 1.0.6 · acidanthera/CpuTscSync- Override one more kernel method IOPlatformActionsPostResume to perform sync as early as possible
- README extended with an additional hint related to TSC_sync_margin=0
RestrictEvents v1.0.7 (LiLu kernel extension)
Release 1.0.7 · acidanthera/RestrictEvents- Fixed detecting CPU core count on Intel CPU with altered topology
- Fixed support on macOS 10.9 - 10.11
- Improve configuration of enabled patches
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias solo en un sentido, y no he tenido que hacer nada más que eliminar una clave que ya no se debe utilizar.
Y volvemos a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.7.8
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados hoy.
La primera prueba la hacemos "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.7.8, publicado el 07 de febrero de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado.
Gigabyte publicó en noviembre una versión actualizada de la BIOS de nuestra Gigabyte Z390 Designare con el nombre F9, que soluciona vulnerabilidades importantes de seguridad, eliminando la letra del final, que había ido evolucionando hasta la versión F9j.
Como indican las notas en su página de soporte, esa versión F9 introdujo el concepto "Capsule BIOS", de forma que no se permite hacer el downgrade hacia versiones anteriores como la F9i, que es la que yo utilizo con mi Sagar Hozkatua.
Ya os comenté que en los foros de tonymacx86 tenemos a un usario llamado Elias64Fr que se ha encargado de modificar la BIOS F9i para añadir las correcciones de la versión F9 oficial, pero sin perder la libertad de la F9i.
Hasta ahora estaba usando la última F9i modificada con el microcódigo 0xEA, pero recientemente ha liberado la última versión que aplica el microcódigo 0xEC (del 24/04/2021) y también actualiza el Intel Management Engine (ME) a la versión 12.0.81.1753 para estar al día de las correcciones sobre las vulnerabilidades que resuelve la F9 oficial.
Os dejo un enlace que contiene tanto la F9i oficial como la F9i modificada, pues es imprescindible instalar la BIOS modificada sobre la BIOS oficial. Si estás usando la F9 sin letra, quédate en ella ya que no podrás actualizarla hacia atrás.
El proceso es muy sencillo, y recomiendo guardar los ajustes de la BIOS en un archivo de perfil que podemos almacenar en el mismo pendrive que usemos para guardar las dos BIOS.
Accedemos a la BIOS y elegimos la opción Q-Flash para actualizar la versión F9i oficial:
Podéis ver que el checksum de la BIOS is 5736
Tras un nuevo reinicio, volvemos a acceder a la BIOS y a la opción Q-Flash para instalar la BIOS modificada por Elias64Fr
Ambas comparten el código de versión y la fecha, pero al estar modificada el checksum es distinto y en este caso es el 3C66.
Otro reinicio e importamos el perfil con los ajustes que hemos guardado para dejar el sistema tal y como lo habíamos dejado, pero con los parches de seguridad aplicados.
Después de la actualización, reviso la prioridad de los discos de arranque, pues como sabéis tengo un disco de 500GB WD SN750 para macOS Monterey, otro de 500GB Samsung 970 EVO Plus para Windows 11 Pro y un tercero de 1TB Samsung EVO Plus para Manjaro y otras distros de Linux.
Después de una actualización de la BIOS, OpenCore pierde el volumen de arranque, y a mi me gusta resetear la NVRAM para tener un arranque limpio.
Y macOS también pierde el volumen de arranque, por lo que vamos a las preferencias para seleccionarlo
Y eso es todo.
Como indican las notas en su página de soporte, esa versión F9 introdujo el concepto "Capsule BIOS", de forma que no se permite hacer el downgrade hacia versiones anteriores como la F9i, que es la que yo utilizo con mi Sagar Hozkatua.
Ya os comenté que en los foros de tonymacx86 tenemos a un usario llamado Elias64Fr que se ha encargado de modificar la BIOS F9i para añadir las correcciones de la versión F9 oficial, pero sin perder la libertad de la F9i.
Hasta ahora estaba usando la última F9i modificada con el microcódigo 0xEA, pero recientemente ha liberado la última versión que aplica el microcódigo 0xEC (del 24/04/2021) y también actualiza el Intel Management Engine (ME) a la versión 12.0.81.1753 para estar al día de las correcciones sobre las vulnerabilidades que resuelve la F9 oficial.
Os dejo un enlace que contiene tanto la F9i oficial como la F9i modificada, pues es imprescindible instalar la BIOS modificada sobre la BIOS oficial. Si estás usando la F9 sin letra, quédate en ella ya que no podrás actualizarla hacia atrás.
BIOS F9i (Mod Microcode 0xEC & ME Security Fixes)
MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.
www.mediafire.com
El proceso es muy sencillo, y recomiendo guardar los ajustes de la BIOS en un archivo de perfil que podemos almacenar en el mismo pendrive que usemos para guardar las dos BIOS.
Accedemos a la BIOS y elegimos la opción Q-Flash para actualizar la versión F9i oficial:
Podéis ver que el checksum de la BIOS is 5736
Tras un nuevo reinicio, volvemos a acceder a la BIOS y a la opción Q-Flash para instalar la BIOS modificada por Elias64Fr
Ambas comparten el código de versión y la fecha, pero al estar modificada el checksum es distinto y en este caso es el 3C66.
Otro reinicio e importamos el perfil con los ajustes que hemos guardado para dejar el sistema tal y como lo habíamos dejado, pero con los parches de seguridad aplicados.
Después de la actualización, reviso la prioridad de los discos de arranque, pues como sabéis tengo un disco de 500GB WD SN750 para macOS Monterey, otro de 500GB Samsung 970 EVO Plus para Windows 11 Pro y un tercero de 1TB Samsung EVO Plus para Manjaro y otras distros de Linux.
Después de una actualización de la BIOS, OpenCore pierde el volumen de arranque, y a mi me gusta resetear la NVRAM para tener un arranque limpio.
Y macOS también pierde el volumen de arranque, por lo que vamos a las preferencias para seleccionarlo
Y eso es todo.
Un mes después, OpenCore se ha actualizado a la versión 0.7.9, y ya he actualizado la carpeta EFI que controla el inicio de mi Sagar Hozkatua con macOS Monterey 12.2.1 (21D62).
Actualización a la versión de OpenCore 0.7.9
github.com
github.com
github.com
github.com
github.com
github.com
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias solo en un sentido, y no he tenido que hacer nada más que añadir un par de claves nuevas.
La variable LogModules en la sección Misc Debug
Y la variable Strategy en la sección Kernel > Block > 0
Volvemos a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.7.8
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados.
La primera prueba la hacemos "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.7.9, publicado el 07 de marzo de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado.
Actualización a la versión de OpenCore 0.7.9
OpenCore v0.7.9
Release 0.7.9 · acidanthera/OpenCorePkg
v0.7.9 Added auto-detect macOS Installer volume name for use when .disk_label file cannot be displayed Added --restore-nosnoop flag to AudioDxe, making v0.7.7 fix for Windows sound opt-in Added ne...
github.com
- Added auto-detect macOS Installer volume name for use when .disk_label file cannot be displayed
- Added --restore-nosnoop flag to AudioDxe, making v0.7.7 fix for Windows sound opt-in
- Added new method to disable trim when SetApfsTrimTimeout is set to zero
- Fixed SetApfsTrimTimeout on macOS 12 (only works when set to zero)
- Added script to build qemu recovery images to macrecovery
- Fixed selecting SecureBootModel on hypervisors (should be x86legacy)
- Added kext blocking Strategy for prelinked and newer
- Added global MSR 35h fix to ProvideCurrentCpuInfo, allowing -cpu host in KVM
- Fixed potential memory corruption with AVX acceleration enabled
- Added LogModules for positive and negative log filtering by modules
- Renamed OpenLinuxBoot driver argument from partuuidopts:{PARTUUID} to autoopts:{PARTUUID}
- Supported booting Linux from stand-alone /boot partition without /loader/entries files (user must specify full kernel boot options)
- Handled XML entities in driver arguments
- Updated underlying EDK II package to edk2-stable202202
OCBinaryData
GitHub - acidanthera/OcBinaryData
Contribute to acidanthera/OcBinaryData development by creating an account on GitHub.
github.com
- Drivers > Solo el archivo HfsPlus.efi
- Resources > Toda las carpetas
AppleALC v1.7.0
Release 1.7.0 · acidanthera/AppleALC
v1.7.0 Fix headphones after sleep on Latitude 7390 2-in-1 (ALC225 layout 30) Added dump_coeff.sh script in Tools to dump processing caps under macOS, plus docs in Wiki Added MSI Modern 15 A10M ALC...
github.com
- Fix headphones after sleep on Latitude 7390 2-in-1 (ALC225 layout 30)
- Added dump_coeff.sh script in Tools to dump processing caps under macOS, plus docs in Wiki
- Added MSI Modern 15 A10M ALC235 layout 29 by @hla63
- Added ALC269 layout-id 26 for Infinix INBook X1 XL11 by @andreszerocross
- Added layout-id 39 for Realtek ALC274 - Mechrevo UmiPro3 (Tongfang GM5MG0Y) by @harahi
- Added layout-id 96 for Realtek ALC257 - Lenovo Thinkpad L390 by @antoniomcr96
- Added ALC883 with fixed MuteGPIO and noise in headphones layout 20 for Atermiter X79G by @samcabral
CpuTscSync v1.0.7 (LiLu Plug-in)
Release 1.0.7 · acidanthera/CpuTscSync
v1.0.7 Find a better place to sync TSC in the kernel (supported since 10.7) boot-args -cputsclock or TSC_sync_margin can be used to select older method to sync TSC
github.com
- Find a better place to sync TSC in the kernel (supported since 10.7)
- boot-args -cputsclock or TSC_sync_margin can be used to select older method to sync TSC
WhateverGreen v1.5.8
Release 1.5.8 · acidanthera/WhateverGreen
v1.5.8 Inverted logic for GVA support, which is now disabled by default and can be enabled by enable-gva-support.
github.com
- Inverted logic for GVA support, which is now disabled by default and can be enabled by enable-gva-support.
VirtualSMC v1.2.9
GitHub - acidanthera/VirtualSMC: SMC emulator layer
SMC emulator layer. Contribute to acidanthera/VirtualSMC development by creating an account on GitHub.
github.com
- Fix infinite panic loop when kernel panic happens on macOS 11 and newer
- Fix rare panics caused by SMCDellSensors (new way of reading SMM was ported from FanIO driver V2.3)
- Added IT8689E device
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias solo en un sentido, y no he tenido que hacer nada más que añadir un par de claves nuevas.
La variable LogModules en la sección Misc Debug
Y la variable Strategy en la sección Kernel > Block > 0
Volvemos a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.7.8
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados.
La primera prueba la hacemos "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.7.9, publicado el 07 de marzo de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado.
Trepamuros
Lanzarredes
Escribo en este hilo que tiene más actividad que el principal de Hackintosh, disculpa DeBilbao.
Por un lado estoy pensando en actualizar la gráfica heredada de mi Mac Pro 5,1 (RX 580 8 GB) pero no quiero gastarme la burrada que piden por una 6800 XT, que sería la ideal para cargas fuertes de trabajo así que la opción "asequible" sería la 6600 XT que está a unos 520 €, elevado también pero no tan escandaloso como las de gama media/alta. Tengo la duda de si notaré un aumento considerable de rendimiento en Premiere/After Effects frente a la 580 o la mayoría de carga en estas tareas se la lleva el procesador (tengo un i7 10700K 8-core).
Y por otro lado, también por el mismo motivo, cuando termine los proyectos en curso voy a probar la SMBIOS del Mac Pro 7,1 que es una máquina más orientada a lo que yo hago que el iMac 20,1. Si mal no recuerdo es la que tú usas.
Le doy una vuelta a ver si me cuadran estos cambios o no merecen la pena.
Un saludo
Por un lado estoy pensando en actualizar la gráfica heredada de mi Mac Pro 5,1 (RX 580 8 GB) pero no quiero gastarme la burrada que piden por una 6800 XT, que sería la ideal para cargas fuertes de trabajo así que la opción "asequible" sería la 6600 XT que está a unos 520 €, elevado también pero no tan escandaloso como las de gama media/alta. Tengo la duda de si notaré un aumento considerable de rendimiento en Premiere/After Effects frente a la 580 o la mayoría de carga en estas tareas se la lleva el procesador (tengo un i7 10700K 8-core).
Y por otro lado, también por el mismo motivo, cuando termine los proyectos en curso voy a probar la SMBIOS del Mac Pro 7,1 que es una máquina más orientada a lo que yo hago que el iMac 20,1. Si mal no recuerdo es la que tú usas.
Le doy una vuelta a ver si me cuadran estos cambios o no merecen la pena.
Un saludo
@Trepamuros viendo que has actualizado tu gráfica por una AMD Radeon 6600 XT y sabiendo que es un elemento crítico en tu flujo de trabajo, te propongo que hagas un benchmark con Geekbench para ver qué puntuaciones obtienes tanto con OpenCL como con Metal.
Consultando la base de datos de Geekbench, la combinación de tu procesador Intel Core i7-10700K con la 6600XT ofrece unas puntuaciones en Metal que oscilan entre los 95.000 y los 99.000 puntos.
La actualización a macOS Monterey 12.3 trajo problemas de rendimiento con las gráficas de las series 5700, 6800 y 6900 como se recoje en este hilo de tonymacx86, y el compañero kalypso ha preparado una miniguía en este hilo para resolver los problemas, en donde se mencionan también a la 6600.
Mi Radeon Vega 56 no está entre las problemáticas y sigo teniendo casi 60.000 puntos en Metal y OpenCL.
Por eso te digo también que habría que revisar tu rendimiento y aplicar la receta si te hace falta.
Si fuese el caso, hay que añadir una configuración en el archivo config.plist que describa la configuración de tu gráfica.
Lo primero es obtener la ruta (el path) de tu gráfica en el registro del sistema. Se puede identificar con el programa IORegistryExplorer, pero con Hackintool es mucho más fácil.
Aquí está el de mi Radeon Vega 56, pero tendrías que hacer lo mismo con la tuya.
Y después solo quedaría añadir en la sección Device Properties de tu config.plist los datos de tu gráfica
Esta serían para la 5500
Esta para la 5700
Esta para una 6600. Desconozco si es la misma que para una 6600XT, supongo que sí.
Esta para una 6800
Y esta última para las 6900
Guardar el archivo config.plist y reiniciar.
@Trepamuros, ya nos cuentas si lo pruebas.
Consultando la base de datos de Geekbench, la combinación de tu procesador Intel Core i7-10700K con la 6600XT ofrece unas puntuaciones en Metal que oscilan entre los 95.000 y los 99.000 puntos.
La actualización a macOS Monterey 12.3 trajo problemas de rendimiento con las gráficas de las series 5700, 6800 y 6900 como se recoje en este hilo de tonymacx86, y el compañero kalypso ha preparado una miniguía en este hilo para resolver los problemas, en donde se mencionan también a la 6600.
Mi Radeon Vega 56 no está entre las problemáticas y sigo teniendo casi 60.000 puntos en Metal y OpenCL.
Por eso te digo también que habría que revisar tu rendimiento y aplicar la receta si te hace falta.
Si fuese el caso, hay que añadir una configuración en el archivo config.plist que describa la configuración de tu gráfica.
Lo primero es obtener la ruta (el path) de tu gráfica en el registro del sistema. Se puede identificar con el programa IORegistryExplorer, pero con Hackintool es mucho más fácil.
Aquí está el de mi Radeon Vega 56, pero tendrías que hacer lo mismo con la tuya.
Y después solo quedaría añadir en la sección Device Properties de tu config.plist los datos de tu gráfica
Esta serían para la 5500
Insertar CODE, HTML o PHP:
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)</key>
<dict>
<key>@0,name</key>
<string>ATY,Python</string>
<key>@1,name</key>
<string>ATY,Python</string>
<key>@2,name</key>
<string>ATY,Python</string>
<key>@3,name</key>
<string>ATY,Python</string>
<key>ATY,EFIVersion</key>
<string>01.01.231</string>
<key>device_type</key>
<string>ATY,PythonParent</string>
</dict>
</dict>
<key>Delete</key>
<dict/>
</dict>Esta para la 5700
Insertar CODE, HTML o PHP:
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)</key>
<dict>
<key>@0,name</key>
<string>ATY,Adder</string>
<key>@1,name</key>
<string>ATY,Adder</string>
<key>@2,name</key>
<string>ATY,Adder</string>
<key>@3,name</key>
<string>ATY,Adder</string>
<key>AAPL00,DualLink</key>
<data>
AQAAAA==
</data>
<key>ATY,Card#</key>
<string>102-D32200-00</string>
<key>ATY,Copyright</key>
<string>Copyright AMD Inc. All Rights Reserved. 2005-2019</string>
<key>ATY,DeviceName</key>
<string>W5700X</string>
<key>ATY,EFIVersion</key>
<string>01.01.190</string>
<key>ATY,FamilyName</key>
<string>Radeon Pro</string>
<key>ATY,Rom#</key>
<string>113-D3220E-190</string>
<key>CAIL_EnableLBPWSupport</key>
<integer>0</integer>
<key>CAIL_EnableMaxPlayloadSizeSync</key>
<integer>1</integer>
<key>CFG_CAA</key>
<integer>0</integer>
<key>CFG_FB_LIMIT</key>
<integer>0</integer>
<key>CFG_FORCE_MAX_DPS</key>
<integer>1</integer>
<key>CFG_GEN_FLAGS</key>
<integer>0</integer>
<key>CFG_NO_MST</key>
<integer>0</integer>
<key>CFG_NVV</key>
<integer>2</integer>
<key>CFG_PAA</key>
<integer>0</integer>
<key>CFG_PULSE_INT</key>
<integer>1</integer>
<key>CFG_TPS1S</key>
<integer>1</integer>
<key>CFG_TRANS_WSRV</key>
<integer>1</integer>
<key>CFG_UFL_CHK</key>
<integer>0</integer>
<key>CFG_UFL_STP</key>
<integer>0</integer>
<key>CFG_USE_AGDC</key>
<integer>1</integer>
<key>CFG_USE_CP2</key>
<integer>1</integer>
<key>CFG_USE_CPSTATUS</key>
<integer>1</integer>
<key>CFG_USE_DPT</key>
<integer>1</integer>
<key>CFG_USE_FBC</key>
<integer>0</integer>
<key>CFG_USE_FBWRKLP</key>
<integer>1</integer>
<key>CFG_USE_FEDS</key>
<integer>1</integer>
<key>CFG_USE_LPT</key>
<integer>1</integer>
<key>CFG_USE_PSR</key>
<integer>0</integer>
<key>CFG_USE_SCANOUT</key>
<integer>1</integer>
<key>CFG_USE_SRRB</key>
<integer>0</integer>
<key>CFG_USE_STUTTER</key>
<integer>1</integer>
<key>CFG_USE_TCON</key>
<integer>1</integer>
<key>PP_DisableDIDT</key>
<integer>1</integer>
<key>PP_DisablePowerContainment</key>
<integer>1</integer>
<key>PP_DisableVoltageIsland</key>
<integer>0</integer>
<key>PP_FuzzyFanControl</key>
<integer>1</integer>
<key>device_type</key>
<string>ATY,AdderParent</string>
<key>hda-gfx</key>
<string>onboard-1</string>
<key>model</key>
<string>Radeon Pro W5700X</string>
<key>name</key>
<string>ATY_GPU</string>
</dict>
</dict>
</dict>Esta para una 6600. Desconozco si es la misma que para una 6600XT, supongo que sí.
Insertar CODE, HTML o PHP:
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)</key>
<dict>
<key>@0,name</key>
<string>ATY,Henbury</string>
<key>@1,name</key>
<string>ATY,Henbury</string>
<key>@2,name</key>
<string>ATY,Henbury</string>
<key>@3,name</key>
<string>ATY,Henbury</string>
<key>device_type</key>
<string>ATY,HenburyParent</string>
</dict>
</dict>
<key>Delete</key>
<dict/>
</dict>Esta para una 6800
Insertar CODE, HTML o PHP:
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)</key>
<dict>
<key>@0,name</key>
<string>ATY,Belknap</string>
<key>@1,name</key>
<string>ATY,Belknap</string>
<key>@2,name</key>
<string>ATY,Belknap</string>
<key>@3,name</key>
<string>ATY,Belknap</string>
<key>device_type</key>
<string>ATY,BelknapParent</string>
</dict>
</dict>
<key>Delete</key>
<dict/>
</dict>Y esta última para las 6900
Insertar CODE, HTML o PHP:
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)</key>
<dict>
<key>@0,name</key>
<string>ATY,Carswell</string>
<key>@1,name</key>
<string>ATY,Carswell</string>
<key>@2,name</key>
<string>ATY,Carswell</string>
<key>@3,name</key>
<string>ATY,Carswell</string>
<key>device_type</key>
<string>ATY,CarswellParent</string>
</dict>
</dict>
<key>Delete</key>
<dict/>
</dict>Guardar el archivo config.plist y reiniciar.
@Trepamuros, ya nos cuentas si lo pruebas.
Trepamuros
Lanzarredes
Gracias compañero bilbaíno, he puesto los resultados en el otro hilo, los comparto aquí también:
Revisa la guía que acabo de comentar y nos cuentas.
Equipos con tu procesador y tu gráfica están entre 95.000 y 99.000 puntos, y eso es un 30% más de tus 75.445.
iMac19,1 - Geekbench
Benchmark results for an iMac19,1 with an Intel Core i7-10700K processor.
browser.geekbench.com
iMac19,1 - Geekbench
Benchmark results for an iMac19,1 with an Intel Core i7-10700K processor.
browser.geekbench.com
iMac19,1 - Geekbench
Benchmark results for an iMac19,1 with an Intel Core i7-10700K processor.
browser.geekbench.com
Trepamuros
Lanzarredes
Acabo de mirarme por encima el hilo de Tonymacx86 y bastantes usuarios mencionan que el update 12.3.1 soluciona los problemas gráficos y también que la 6600 XT no está afectada en cuanto a rendimiento. No sé qué variables tener en cuenta para esas puntuaciones más altas que han conseguido los usuarios que superan los 95.000.
Para ser práctico he hecho una prueba directamente con Premiere Pro, el programa con el que más trabajo: he exportado un proyecto que acabé la semana pasada cuando aún tenía la RX 580 (tardó unos 10 minutos en renderizar el vídeo) y con la 6600 XT me ha tardado menos de la mitad, así que por este lado me ha dejado muy satisfecho el upgrade de gráfica. Sigo investigando porque me da cosa tocar la config.plist y fastidiar algo, que soy un poco manazas y ya tuve un susto gordo hace poco en el que no me arrancaba la máquina ni con una EFI de seguridad que tenía a buen recaudo
Gracias de nuevo por hacer eco del asunto, DeBilbao
Para ser práctico he hecho una prueba directamente con Premiere Pro, el programa con el que más trabajo: he exportado un proyecto que acabé la semana pasada cuando aún tenía la RX 580 (tardó unos 10 minutos en renderizar el vídeo) y con la 6600 XT me ha tardado menos de la mitad, así que por este lado me ha dejado muy satisfecho el upgrade de gráfica. Sigo investigando porque me da cosa tocar la config.plist y fastidiar algo, que soy un poco manazas y ya tuve un susto gordo hace poco en el que no me arrancaba la máquina ni con una EFI de seguridad que tenía a buen recaudo
Gracias de nuevo por hacer eco del asunto, DeBilbao
Última edición:
Es un tema al que no le había hecho mucho caso porque mi gráfica no estaba afectada, pero viendo que habías cambiado la tuya le he dado un vistazo y he dado la voz de alerta…
Mucho mejor que no tengas que tocar nada.
Y cuenta qué es lo que te pasó con ese “susto gordo”, es raro que un equipo no arranque con la EFI de seguridad.
Mucho mejor que no tengas que tocar nada.
Y cuenta qué es lo que te pasó con ese “susto gordo”, es raro que un equipo no arranque con la EFI de seguridad.
Trepamuros
Lanzarredes
Desde que empecé con Hackintosh uso las EFI actualizadas que CaseySJ comparte cada mes en Tonymacx86. A nivel de hardware tenemos casi el mismo equipo y todo me ha funcionado a la perfección desde el primer día (no es lo óptimo pero no me fío actualizando OpenCore a mano porque no controlo el proceso y necesito el Mac operativo para trabajar).
Desde la versión 0.7.9 el update lo hace mediante la app Hackindrom, que en teoría es tan sencillo como montar la partición, hacer click derecho en ella y pulsar Update. Al ser la primera vez algo hice mal y al reiniciar el Mac, éste se quedó atascado en la pantalla de carga con el símbolo de la manzana. Probé a arrancar desde el pendrive que tengo con el backup de la EFI pero no había manera.
Tras pedir prestado un Macbook a un familiar y formatear repetidamente varios pendrives, probé las últimas EFIs funcionales que tenía guardadas y revisé la Bios, por descartar problemas. Resulta que el perfil con los settings de arranque, perfiles de memorias XMP, etc. se había resetado. Tras configurar de nuevo la Bios y probar de nuevo una EFI antigua, el Mac por fin pasó la pantalla de carga y pude iniciar sesión.
Al entrar comprobé que Hackindrom me había cambiado el nombre de la EFI en la partición de arranque así que la restauré con la copia guardada de OC 0.7.8 que sabía que iba bien e hice una vez más un backup del perfil de la bios. Hasta hoy sigue funcionando todo perfecto, yo creo que el problema fue una combinación de EFI corrupta y reseteo de bios. En año y medio es la primera vez que me pasa algo así y no sé como se han podido alterar esos ajustes pero es extraño que haya sucedido justo cuando uso Hackindrom por primera vez.
Ahora que tendré otro Mac ya puedo arriesgarme a hacer cambios, pero lo pasé realmente mal ese fin de semana que me "cargué" el equipo
Última edición:
Este mes les ha costado un poco más de tiempo publicar la actualización, pero ya tenemos OpenCore en versión 0.8.0, y ya he actualizado la carpeta EFI que controla el inicio de mi Sagar Hozkatua con macOS Monterey 12.3.1 (21E258).
Actualización a la versión de OpenCore 0.8.0
github.com
github.com
github.com
No hay más novedades. El bootloader y un par de extensiones de kernel actualizadas.
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias en ambos sentidos, pero la actualización es sencilla: añadir un par de variables nuevas en la sección Kernel y otra clave con dos valores en la sección Misc que viene a sustituir a una variable que hay que eliminar.
En la sección Kernel copiamos las variables CustomPciSerialDevice y ForceAquantiaEthernet del archivo sample.plist y las pegamos en nuestro archivo config.plist
Y lo mismo con la clave Serial, que contiene dos variables: Init y Override, ambas con valor "NO".
Vuelvo a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.8.0
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados. macOS dice "hoy" refiriéndose a la fecha de ayer 18 de abril de 2022.
De nuevo y como siempre, la primera prueba la hago "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.8.0, publicado el 18 de abril de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado y en particular que los dispositivos USB siguen bien identificados.
Actualización a la versión de OpenCore 0.8.0
OpenCore v0.8.0
Release 0.8.0 · acidanthera/OpenCorePkg
v0.8.0 Added support for early log preservation Switched to Python 3 in scripts (use python /path/to/script to force Python 2) Added ForceAquantiaEthernet for Aquantia AQtion AQC-107s based 10GbE ...
github.com
- Added support for early log preservation
- Switched to Python 3 in scripts (use python /path/to/script to force Python 2)
- Added ForceAquantiaEthernet for Aquantia AQtion AQC-107s based 10GbE network cards support, thx @Mieze and @Shikumo
- Updated builtin firmware versions for SMBIOS and the rest
- Added Misc -> Serial section to customise serial port properties
- Added CustomPciSerialDevice quirk for XNU to correctly recognise customised external serial devices
AppleALC v1.7.1
Release 1.7.1 · acidanthera/AppleALC
v1.7.1 Fixed EAPD for layout 28 ALC269 by @samcabral Fixed wrong file name in ALC287 info.plist Added dump for ALC225 layout 30 by @usr-sse2 Added Lenovo M920x for ALC235 LayoutID=72 by @meloay Fi...
github.com
- Fixed EAPD for layout 28 ALC269 by @samcabral
- Fixed wrong file name in ALC287 info.plist
- Added dump for ALC225 layout 30 by @usr-sse2
- Added Lenovo M920x for ALC235 LayoutID=72 by @meloay
- Fixed ALC298 layout-id 11 for Alienware 17 R4 2.1ch by @Rockjesus.cn
- Fixed MSI MPG Z490 Gaming Plus Sound issue after booting from Windows by @JanoMorano
- Added NUC8I5BEH JUST MIC layout-id 88 by @frozenzero123
- Added layoutid 59 ALC292 for Dell M4800 with dockstation support by @hansyao
CpuTscSync v1.0.8 (LiLu Plug-in)
Release 1.0.8 · acidanthera/CpuTscSync
v1.0.8 Fix old sync logic used when boot-arg -cputsclock is specified
github.com
- Fix old sync logic used when boot-arg -cputsclock is specified
No hay más novedades. El bootloader y un par de extensiones de kernel actualizadas.
La comparación del archivo config.plist con el sample.plist de la nueva versión arroja diferencias en ambos sentidos, pero la actualización es sencilla: añadir un par de variables nuevas en la sección Kernel y otra clave con dos valores en la sección Misc que viene a sustituir a una variable que hay que eliminar.
En la sección Kernel copiamos las variables CustomPciSerialDevice y ForceAquantiaEthernet del archivo sample.plist y las pegamos en nuestro archivo config.plist
Y lo mismo con la clave Serial, que contiene dos variables: Init y Override, ambas con valor "NO".
Vuelvo a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.8.0
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados. macOS dice "hoy" refiriéndose a la fecha de ayer 18 de abril de 2022.
De nuevo y como siempre, la primera prueba la hago "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.8.0, publicado el 18 de abril de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado y en particular que los dispositivos USB siguen bien identificados.
Hallowed
Miembro habitual
- Mensajes
- 6.349
- Reacciones
- 7.342
Una duda sobre este tema... ¿Tiene la comunidad previsto algo para cuando Apple deje de publicar versiones X86? Supongo que quedarán unos cuantos años, pero tampoco tantos... ¿Hay algo que se pueda hacer o será el fin del hackintosh?
Sin contar virtualización, claro.
Sin contar virtualización, claro.
No sé lo que tiene previsto la comunidad, pero lo que me dice el sentido común es que todo esto existe porque Apple tiene muchos equipos con un hardware muy parecido al existente en el mundo de los PCs, y el proyecto OpenCore - y antes otros - se han centrado en ver cómo conseguir evitar las restricciones impuestas por Apple, presentando ese hardware equivalente como si fuera exactamente el mismo en el proceso de carga del Kernel.
¿Eso se puede conseguir con los nuevos equipos de Apple? Salvo que alguien me dijera que los procesadores Apple Silicon son equivalentes a otro hardware (como la arquitectura ARM), lo veo muy complicado.
El final del Hackintosh vendrá cuando el sistema operativo de Apple solo de soporte a equipos con procesadores Apple Silicon. Ese día nuestras máquinas no dejarán de funcionar, pero no podrán seguir evolucionando.
Creo que queda bastante tiempo para que eso pase y por el camino seguro que sucede algo revolucionario...
macOS 12.4 (21F79) funciona perfectamente en mi Sagar Hozkatua y con OpenCore 0.8.0
Tenéis más detalles de cómo instalar la Release Candidate en el hilo de macOS Monterey
Tenéis más detalles de cómo instalar la Release Candidate en el hilo de macOS Monterey
Parece que el equipo de OpenCore ha pasado de plazos del orden de 30 días a plazos del orden de 45 días, pero siguen fiel a su cita con quienes utilizamos su gestor de arranque.
Ya tenemos disponible la versión 0.8.1 de OpenCore en versión 0.8.0, y ya he actualizado la carpeta EFI que controla el inicio de mi Sagar Hozkatua con macOS Monterey 12.4 (21F79).
Actualización a la versión de OpenCore 0.8.1
La comparación del archivo config.plist con el sample.plist de la nueva versión solo indica que un par de variables en el entorno de seguridad han sido eliminadas,
Así que procedo a eliminarlas
Y vuelvo a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.8.1
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados. macOS dice "hoy" refiriéndose a la fecha de ayer 18 de abril de 2022.
De nuevo y como siempre, la primera prueba la hago "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.8.1, publicado el 06 de junio de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado y en particular que los dispositivos USB siguen bien identificados.
Hackintool está actualizado a la versión 3.8.7, podéis descargarlo desde su repositorio en Github
github.com
Ya tenemos disponible la versión 0.8.1 de OpenCore en versión 0.8.0, y ya he actualizado la carpeta EFI que controla el inicio de mi Sagar Hozkatua con macOS Monterey 12.4 (21F79).
Actualización a la versión de OpenCore 0.8.1
OpenCore v0.8.1
Release 0.8.1 · acidanthera/OpenCorePkg- Improved ExtendBTFeatureFlags quirk on newer macOS versions, thx @lvs1974
- Added notes about DMAR table and ForceAquantiaEthernet, thx @kokowski
- Added System option in LauncherOption property, thx @stevezhengshiqi
- Updated note about CustomPciSerialDevice, thx @joevt
- Added read-only driver for NTFS
- Switched Reset NVRAM and Toggle SIP to configurable boot entry protocol drivers
- Supported optional Apple firmware-native NVRAM reset, thx @syncretic
- Supported NVRAM reset optionally retaining BIOS boot entries
- Supported user specified csr-active-config value for Toggle SIP
- Added optional Enabled and Disabled flavours for Toggle SIP (allows theme designers to provide distinct icons)
- Added PIIX4 ACPI PM timer detection for TSC calculations on Hyper-V Gen1 VMs
BrcmPatchRAM v2.6.2
- Added Skip Address Check patch for 12.4 Beta 3 and newer (thx @khronokernel)
AppleALC v1.7.2
Release 1.7.2 · acidanthera/AppleALC- Added layout-id 97 ALC257 for Lenovo Thinkpad T490 by @savvamitrofanov
- Update controller patch for 400 series 0x06C8 to fix HDMI audio by @Core-i99
- Added ALC255(3234) layout-id 255 for Dell Inspiron 5548 by CynCYX
- Added ALC897 layout-id 77 for ONDA H510 IPC by LewandowskiZ
- Fix Legion Y9000X 2020 Speaker Mute disabled issue by SukkaW
WhateverGreen v1.5.9
Release 1.5.9 · acidanthera/WhateverGreen- Add AMD prefix for all Radeon cards to follow latest Apple naming scheme
No hay más novedades. El bootloader y un tres extensiones de kernel actualizadas.La comparación del archivo config.plist con el sample.plist de la nueva versión solo indica que un par de variables en el entorno de seguridad han sido eliminadas,
Así que procedo a eliminarlas
Y vuelvo a comprobar con ocConfigCompare.command que todo está bien aplicado y que no hay diferencias entre nuestro archivo config.plist y el sample.plist que acompaña a la descarga de OpenCore 0.8.1
Como siempre, antes de reiniciar, reviso el archivo config.list con ProperTree, haciendo un OC Snapshot, que lee la carpeta y añade entradas al archivo config.plist si no las encuentra y las elimina si sobra. Esto sucede si hemos añadido o quitado un Kext, por ejemplo.
Así ha quedado definitivamente mi carpeta EFI. En la selección, los elementos que han sido modificados. macOS dice "hoy" refiriéndose a la fecha de ayer 18 de abril de 2022.
De nuevo y como siempre, la primera prueba la hago "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.8.1, publicado el 06 de junio de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado y en particular que los dispositivos USB siguen bien identificados.
Hackintool está actualizado a la versión 3.8.7, podéis descargarlo desde su repositorio en Github
GitHub - benbaker76/Hackintool: The Swiss army knife of vanilla Hackintoshing
The Swiss army knife of vanilla Hackintoshing. Contribute to benbaker76/Hackintool development by creating an account on GitHub.
github.com
La última versión 0.8.2 de OpenCore nos trae la compatibilidad con macOS Ventura, adaptando tanto el gestor de arranque como la mayoría de las extensiones de kernel para que puedan soportar la nueva versión 13 del sistema de Apple, cuya beta pública se espera para este mes de julio y seguramente hasta el último trimestre no tengamos la definitiva.
Como de costumbre, he actualizado la carpeta EFI que controla el inicio de mi Sagar Hozkatua, actualmente ejecutando macOS Monterey 12.4 (21F79).
Actualización a la versión de OpenCore 0.8.2
github.com
github.com
github.com
github.com
github.com
github.com
Así ha quedado tras la actualización. En rojo los elementos actualizados:
La comparación del archivo config.plist con el sample.plist de la nueva versión no indica ni un solo cambio, así que esta vez lo dejamos tal cual está ya que tampoco hay extensiones ni componentes nuevos:
De nuevo y como siempre, la primera prueba la hago "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.8.2, publicado el 04 de julio de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado y en particular que los dispositivos USB siguen bien identificados.
Hackintool está actualizado a la versión 3.8.7, podéis descargarlo desde su repositorio en Github
github.com
Como de costumbre, he actualizado la carpeta EFI que controla el inicio de mi Sagar Hozkatua, actualmente ejecutando macOS Monterey 12.4 (21F79).
Actualización a la versión de OpenCore 0.8.2
OpenCore v0.8.2
Release 0.8.2 · acidanthera/OpenCorePkg
v0.8.2 Fixed AppleCpuPmCfgLock on macOS 13 Fixed DummyPowerManagement on macOS 13 Updated builtin firmware versions for SMBIOS and the rest Added macOS 13 support for AvoidRuntimeDefrag Booter qui...
github.com
- Fixed AppleCpuPmCfgLock on macOS 13
- Fixed DummyPowerManagement on macOS 13
- Updated builtin firmware versions for SMBIOS and the rest
- Added macOS 13 support for AvoidRuntimeDefrag Booter quirk
- Added injected kext bundle version printing in DEBUG builds
- Added Linux compatibility for CreateVault scripts
AppleALC v1.7.3
Release 1.7.3 · acidanthera/AppleALC
v1.7.3 Added constants for macOS 13 support Fix sleep breaking earphone support on ALC295 layout-id 13 by Mahas1 Fixed NUC8I5BEH JUST MIC ALC235 layout-id 88 by @frozenzero123 Added ALC269 VC layo...
github.com
- Added constants for macOS 13 support
- Fix sleep breaking earphone support on ALC295 layout-id 13 by Mahas1
- Fixed NUC8I5BEH JUST MIC ALC235 layout-id 88 by @frozenzero123
- Added ALC269 VC layout-id 39 with support for LineIn and LineOut of Docking Stations 4337 and 4338 for Lenovo T530 with Docking Stations 4437 and 4338 by 5T33Z0
- Added ALC235 layout-id 33 for Lenovo A340-22IWL with support for Internal Speakers, Headphone, and LineIn (External Mic).
- Added new codec revision-id 0x100500 for ALC897 by R-a-s-c-a-l
- Added ALC294 layout-id 15 for Zenbook UX434 by wern-apfel
- Added ALC287 layout-id 21 for Lenovo Yoga Slim 7-14IIL05 by Andres ZeroCross
- Added ALC280 layout-id 18 for Dell OptiPlex 9020 AIO ALC280 by james090500
BrcmPatchRAM v2.6.3
Release 2.6.3 · acidanthera/BrcmPatchRAM
v2.6.3 Added constants for macOS 13 support Fixed Skip Address Check patch for 13.0 Beta 1 and newer
github.com
- Added constants for macOS 13 support
- Fixed Skip Address Check patch for 13.0 Beta 1 and newer
NVMeFix v1.1.0
- Added constants for macOS 13 support
VirtualSMC v1.3.0
- Added preliminary macOS 13 support
WhateverGreen v1.6.0
Release 1.6.0 · acidanthera/WhateverGreen
v1.6.0 Added constants required for macOS 13 update Added Skylake graphics spoofing support on macOS 13+ by @dhinakg Modified brightness change requests to replace previous requests instead of que...
github.com
- Added constants required for macOS 13 update
- Added Skylake graphics spoofing support on macOS 13+ by @dhinakg
- Modified brightness change requests to replace previous requests instead of queuing
LiLu v1.6.1
Release 1.6.1 · acidanthera/Lilu
v1.6.1 Allow loading on macOS 13 without -lilubetaall Added Ventura dyld shared cache pathing Changed SKL default ig-platform-id to KBL on macOS 13+ Added patch with masking support
github.com
- Allow loading on macOS 13 without -lilubetaall
- Added Ventura dyld shared cache pathing
- Changed SKL default ig-platform-id to KBL on macOS 13+
- Added patch with masking support
CpuTscSync (LiLu plug-in) v1.0.9
- Added constants for macOS 13 support
RestrictEvents (LiLu plug-in RAM) v1.0.8
Release 1.0.8 · acidanthera/RestrictEvents
v1.0.8 Added constants for macOS 13 support Do not enable Memory and PCI UI patching on real Macs in auto mode Added MacPro7,1 memory patch for macOS 13 System Settings->General->About
github.com
- Added constants for macOS 13 support
- Do not enable Memory and PCI UI patching on real Macs in auto mode
- Added MacPro7,1 memory patch for macOS 13 System Settings->General->About
Prácticamente se ha actualizado todas las extensiones que utilizo. Solo me quedarían la que controla la tarjeta de red principal (IntelMausi, que uso con un mod para poder usarla con WakeOnLAN), la de la tarjeta de red secundaria (SmallTree I211), y los inyectores USB (USB InjectAll y USBWakeFixup).Así ha quedado tras la actualización. En rojo los elementos actualizados:
La comparación del archivo config.plist con el sample.plist de la nueva versión no indica ni un solo cambio, así que esta vez lo dejamos tal cual está ya que tampoco hay extensiones ni componentes nuevos:
De nuevo y como siempre, la primera prueba la hago "sin riesgo", copiando la carpeta EFI al pendrive de instalación de macOS Monterey, y reiniciando el equipo desde el mismo. Así, si tuviéramos un problema no habríamos puesto en riesgo nuestra instalación.
Comprobado que todo va bien, sustituimos la carpeta EFI de nuestro disco de arranque, en mi caso el WD SN750 de 500GB.
En la parte inferior derecha de la pantalla del "picker" de OpenCore, podemos comprobar que estamos usando OpenCore 0.8.2, publicado el 04 de julio de 2022.
Y tras arrancar, todo funciona correctamente. Como de costumbre, me he dado una vuelta por Hackintool para comprobar que el hardware está correctamente identificado y en particular que los dispositivos USB siguen bien identificados.
Hackintool está actualizado a la versión 3.8.7, podéis descargarlo desde su repositorio en Github
GitHub - benbaker76/Hackintool: The Swiss army knife of vanilla Hackintoshing
The Swiss army knife of vanilla Hackintoshing. Contribute to benbaker76/Hackintool development by creating an account on GitHub.
github.com
La última versión pública del gestor de arranque OpenCore es la 0.8.2 y no soporta macOS Ventura, pero la última versión beta 0.8.3 y el correspondiente set de extensiones de kernel, ofrecen ya compatibilidad completa con la última versión 13 de macOS y todos los dispositivos del sistema se reconocen perfectamente.
Así que he instalado en mi Sagar Hozkatua la última beta 3 de macOS Ventura, con número de build 22A5295i, liberada por Apple el pasado 11 de julio para desarrolladores y también como primera beta pública para todos los usuarios.
Siendo una versión nueva de macOS, me gusta hacerlo de forma limpia y no como actualización de Monterey, y he preparado un pendrive USB de 16GB con el instalador descargado desde los servidores de Apple. Solo hay que hacer doble clic en el programa InstallAssistant.pkg y te dejará un instalador de más de 12GB en la carpeta de aplicaciones.
Y para crear el pendrive, previamente inicializado en formato macOS (con registro) y con mapa de particiones GUID, solo hay que ejecutar este comando (cambiar USB_16GB por el nombre que le hayáis dado).
A partir de ahí solo hay que iniciar desde el pendrive y seguir el asistente. Si es un Mac genuino sin ningún paso previo y si es con OpenCore como en mi caso, copiando previamente la carpeta EFI en la partición EFI.
Os dejo los enlaces de las versiones que estoy usando por si os apetece probar.
Lo he instalado en un disco SSD SATA auxiliar Kingston de 120GB y lo poco que he visto por el momento en términos de fluidez y rapidez de respuesta me parece bien, pero necesito usarlo más para sacar conclusiones.
Iré compartiendo por aquí mis venturas y desventuras con esta nueva versión de macOS.
Así que he instalado en mi Sagar Hozkatua la última beta 3 de macOS Ventura, con número de build 22A5295i, liberada por Apple el pasado 11 de julio para desarrolladores y también como primera beta pública para todos los usuarios.
Siendo una versión nueva de macOS, me gusta hacerlo de forma limpia y no como actualización de Monterey, y he preparado un pendrive USB de 16GB con el instalador descargado desde los servidores de Apple. Solo hay que hacer doble clic en el programa InstallAssistant.pkg y te dejará un instalador de más de 12GB en la carpeta de aplicaciones.
Insertar CODE, HTML o PHP:
https://swcdn.apple.com/content/downloads/26/02/012-38308-A_T09BINQJZO/ktkggwae70k7cxffui52ggv4xd3xbpwuuw/InstallAssistant.pkgY para crear el pendrive, previamente inicializado en formato macOS (con registro) y con mapa de particiones GUID, solo hay que ejecutar este comando (cambiar USB_16GB por el nombre que le hayáis dado).
Insertar CODE, HTML o PHP:
sudo /Applications/Install\ macOS\ Ventura\ beta.app/Contents/Resources/createinstallmedia --volume /Volumes/USB_16GBA partir de ahí solo hay que iniciar desde el pendrive y seguir el asistente. Si es un Mac genuino sin ningún paso previo y si es con OpenCore como en mi caso, copiando previamente la carpeta EFI en la partición EFI.
Os dejo los enlaces de las versiones que estoy usando por si os apetece probar.
- Gestor de arranque
- OpenCorePkg 0.8.3 como director de orquesta
- Extensiones de Kernel
- AppleALC 1.7.4 para el soporte nativo de audio (AppleALC.kext)
- BrcmPatchRAM 2.6.3 para el soporte de Bluethooth para dispositivos Broadcom (BlueToolFixup.kext, BrcmFirmwareData.kext y BrcmPatchRAM3.kext)
- Lilu 1.6.2 como gestor de API para el parcheo de extensiones de kernel con estos plug-ins (Lilu.kext)
- BrightnessKeys 1.0.3 para el control de las teclas de brillo de la pantalla (BrightnessKeys.kext)
- CpuTscSync 1.0.9 para la sincronización de los contadores TSC entre los cores de la CPU (CpuTscSync.kext)
- NVMeFix 1.0.6 para mejorar la compatibilidad de discos SSD que no sean de Apple (NVMeFix.kext)
- RestrictEvents 1.0.8 para conseguir que la memoria y los buses PCI sean bien reportados (RestrictEvents.kext)
- VirtualSMC 1.3.0 para conseguir emular el controlador del sistema SMC (VirtualSMC.kext, SMCProcessor.kext y SMCSuperIO.kext)
- WhateverGreen 1.6.1 para el soporte de las tarjetas gráficas (WhateverGreen.kext)
- IntelMausi 1.0.8 para el soporte de tarjetas de red Intel, en mi caso una de la serie I219-V
- SmallTreeIntel82576.kext para la tarjeta de red secundaria
- USBInjectAll.kext, USBWakeFixup.kext y XHCI-unsupported.kext para el soporte de USB
Lo he instalado en un disco SSD SATA auxiliar Kingston de 120GB y lo poco que he visto por el momento en términos de fluidez y rapidez de respuesta me parece bien, pero necesito usarlo más para sacar conclusiones.
Iré compartiendo por aquí mis venturas y desventuras con esta nueva versión de macOS.