OpenCore 1.0.3 ya está disponible. Hay bastantes cambios y mejoras pero la mayoría no son perceptibles para el usuario final, sobre todo si la versión 1.0.2 funcionaba bien. Puedes descargarlo desde Acidanthera.
Cambios principales
Compatibilidad con la familia de CPU AMD 1AH
Se corrigió la transferencia EHCI en OpenDuet, lo que provocaba que las máquinas más antiguas se bloquearan al iniciarse
Compatibilidad con CPU Arrow Lake y Raptor Lake
Se corrigió un fallo con vault sign.command
Se añadió el driver OpenNetworkBoot para admitir el arranque HTTP(S) y PXE.
OpenCore 1.0.2 ya está disponible. Al igual que en la versión anterior, hay bastantes cambios aunque la mayoría no son perceptibles para el usuario final. Puedes obtenerla en Acidanthera.
Cambios principales
Docs: actualizado el texto de Booter >> Quirks >> FixupAppleEfiImages. FixupAppleEfiImages corrige errores de permisos y secciones en imágenes boot.efi de macOS (ver Nota)
Se corrigió un error en macrecovery al ejecutarse sin interfaz gráfica
Se añadió soporte para AMD_CPU_EXT_FAMILY_1AH
Se actualizaron las versiones de firmware integradas para SMBIOS
Se volvió a habilitar el parche (corregido) MSR_MISC_PWR_MGMT de XcpmExtraMsrs en macOS 12+
Se corrigió la selección de dispositivo de arranque con discos VirtIO usados para instalaciones de macOS
UEFI >> se ha añadido la opción Unload (Array) para desactivar drivers existentes en el firmware.
Usuarios de macOS Catalina y posteriores que utilizan SMBIOS de MacPro7,1 reciben un aviso de error al arrancar: MEMORY MODULES MISCONFIGURED – More than the maximum supported memory is installed in your Mac. El modelo MacPro7,1 fue puesto a la venta en 2019 y es el Mac Intel más potente y modular, con una orientación claramente profesional. Lleva una CPU Intel Xeon de 8 a 28 núcleos según modelos y tarjetas gráficas AMD Radeon Pro 580X. Carece de iGPU. Aunque no parece un modelo de SMBIOS adecuado a la mayoría de los hackintosh, algunos usuarios que han montado equipos de alto rendimiento con CPU potentes (sobre todo si no tienen gráfica integrada) y mucha memoria RAM lo utilizan.
Traducción con aportaciones propias de la guía Fixing MacPro7,1 Memory Errors, publicada por RTHPJM en GitHub, que es información ampliada de la guía original de Dortania.
No está claro el mecanismo por el que se genera el aviso. Hasta el lanzamiento de Big Sur, el plugin de Lilu MacProMemoryNotificationDisabler.kext desarrollado por IOIIIO solucionaba el problema y el aviso dejaba de aparecer. Pero esta kext no funciona en Big Sur. Lilu aplica los parches como el de esta kext en el espacio de usuario al que Big Sur no deja acceder para esta tarea por lo que ha dejado de funcionar.
Avisos de error que pueden aparecer en el Escritorio:
Todos los certificados UEFI actuales de Microsoftcaducan en 2026. Estos incluyen Microsoft Corporation KEK CA 2011, almacenado en la base de datos KEK, y dos certificados almacenados en la db llamados Microsoft Windows Production PCA 2011, que firma el gestor de arranque de Windows, y Microsoft UEFI CA 2011 (o UEFI CA de terceros) que firma componentes de controladores de hardware y sistemas operativos de terceros.
Microsoft está migrando a otros nuevos. La primera actualización es añadir Microsoft Windows UEFI CA 2023 a la base de datos del firmware. El nuevo certificado se utilizará para firmar los componentes de arranque de Windows antes de que expire la CA de producción de Microsoft Windows 2011.
BIOS bloqueada tras actuar en las claves seguras del firmware seguras: después de modificar variables seguras (actualizar, agregar, eliminar o restablecer los valores predeterminados), pueden ocurrir problemas, algunos de los cuales no son fáciles de solucionar:
Problemas detectados:
Las variables seguras no se dejan modificar con mensajes «Security violation» o «Try after system reboot» o «Secure variables are locked down»
Arranque del BIOS no pasa el POST con pitidos de error.
Por lo que he leído en diferentes lugares, estos problemas parecen ser más frecuentes en las placas base Gigabyte pero es algo de lo que no puedo estar seguro. Mi placa base es Gigabyte (Z390 Aorus Elite) y ha presentado estos problemas en varias ocasiones.
Como parte del proceso de habilitar UEFI Secure Boot con OpenCore, hay que insertar los archivos de firma digital en el firmware, reemplazando las variables existentes en este orden:
db.auth >> DB (archivo de sitios autorizados)
kek.auth >> KEK (claves para el intercambio de claves)
pk.auth >> PK (clave de la plataforma).
Esto se puede hacer de 2 maneras: menú de configuración del BIOS o KeyTool.
BIOS
En la sección Secure Boot suele haber opciones para restaurar las claves predeterminadas de fábrica o editar variables por separado. En mi placa base (Z390 Aorus Elite), este menú está en Boot >> pestaña Secure Boot >> Key Management.
El firmware UEFI de las placas base tiene la capacidad de arranque seguro de forma que sólo se permiten los archivos del boot loader firmados digitalmente con las claves que están integradas en el firmware. Con UEFI Secure Boot habilitado: – Windows puede arrancar ya que los firmware incorporan certificados de Microsoft (a veces también certificados del fabricante de la placa base) – macOS no puede arrancar; es necesario un sistema Linux en el que generar las claves y firmar con ellas los archivos de OpenCore, este es el motivo por el que actualmente arrancamos OpenCore con UEFI Secure Boot deshabilitado.
Los artículos de sakaki y de Ubuntu plantean cómo arrancar Linux con UEFI Secure Boot activado pero khronokernel y profzei se refieren específicamente a OpenCore y macOS. Los 4 artículos coinciden en la necesidad de hacerlo desde un sistema Linux ya que las herramientas requeridas no existen para macOS. El sistema Linux necesario para firmar los archivos de OpenCore puede suponer un inconveniente significativo por el trabajo que conlleva su instalación y configuración (bien en disco independiente o en máquina virtual). Una vez en Linux, todo se hace desde Terminal por lo que gran parte del sistema instalado realmente no hace falta. Esta tarea se puede simplificar gracias a una infraestructura no demasiado utilizada que existe en Windows 10 (compilación 18917 o posterior) y Windows 11: Windows Subsystem for Linux (WSL), gracias a la cual podemos arrancar una imagen genuina de Ubuntu proporcionada por Canonical. Esto posibilita la ejecución de comandos de forma nativa en un terminal de Bash dentro de un entorno Windows que se comporta como Linux.
UEFI Secure Boot y OpenCore con máquina virtual de Ubuntu en macOS: Esta es una forma de habilitar UEFI Secure Boot con OpenCore sin tener que instalar Windows o crear un dispositivo USB con Linux. Todo se realiza desde macOS. La función de portapapeles y carpeta compartidos, que permiten intercambiar texto y archivos entre macOS y Linux, facilita la tarea.
UTM
UTM es una aplicación que permite utilizar máquinas virtuales en macOS e iOS. Es un software gratuito y abierto. Información y descargas están disponibles en GitHub y en el sitio web.
UTM ofrece máquinas virtuales preconfiguradas que sólo debes adjuntar a la app e iniciar, no es necesario instalar previamente el sistema operativo. Puedes visitar la Galería de Máquinas Virtuales.
Entre las máquinas virtuales preinstaladas no existe Ubuntu 22.04 pero UTM tiene una guía para descargar e instalar esta versión de Ubuntu. He seguido esta guía para tener un sistema virtual Ubuntu 22.04 en macOS.
