Poseo un MacBook Air de 2014 que jamás me dio un problema hasta que un buen día arrancó con los ventiladores a miles de revoluciones y el ordenador pasó prácticamente a ser inútil, ya que el uso de la CPU se mostraba continuamente por encima del 100%. Abriendo el Monitor de Actividad, puedes comprobara que el culpable de este problema es el kernel_task.
Si haces una búsqueda rápida en Google, comprobarás que siempre que un equipo de Mac tiene un problema físico, el kernel_task se dispara y los motivos son diversos. Desde problemas de refrigeración, corrupción del Sistema Operativo, de algún driver de terceros o, como en mi caso, algún fallo con la placa base.
Existen diferentes métodos para pasarle un test hardware al equipo que en este artículo no voy a tratar porque son fáciles de localizar en internet.
En mi caso, mi Macbook Air ha sufrido un fallo físico en los sensores de temperatura. Esto hace que el sistema, preventivamente y a pesar de que aparentemente el equipo no esté caliente, provoca que el kernel_task (proceso base del sistema operativo MacOS) empiece a comerse la CPU y provoque que los ventiladores se pongan a máximas revoluciones con el objeto de proteger el hardware.
Comprobé que instalando Windows, el sistema era completamente estable y lo planteé como solución definitiva. Sin embargo, prefiero manejarme con MacOS y empecé a investigar cómo podía solucionarlo. A modo resumen, localicé la forma: hay que desactivar (eliminar) una serie de drivers del sistema para que el kernel_task ignore los sensores de temperatura e instalar Macs Fan Control para delegar el control de los ventiladores en algún sensor de temperatura que continúe operativo.
En este artículo, os voy a enseñar a desactivar el driver IOPlatformPluginFamily.kext, responsable de poner preventivamente el kernel_task a una CPU superior a incluso 400%. Ya que con el cambio que ha provocado MacOS BigSur, el procedimiento clásico que se encuentra por internet, no es viable. MacOS, para protegerse, ahora monta el sistema operativo en Read Only y eso hace que eliminar el kext no sea suficiente, hay que hacer que persista el cambio.
Por favor, antes de comenzar a ejecutar los comandos en el equipo, recomiendo leer todo el artículo para que os podáis hacer una idea de lo que vais a hacer. No me hago responsable de lo que pueda suceder, ejecutar bajo vuestra responsabilidad 🙂
Allá vamos:
Lo primero que vamos a hacer es desactivar una serie de métodos de protección que tiene MacOS. Para ello, hemos de arrancar MacOS en modo seguro. Para ello durante el arranque pulsar CMD + R.
A continuación, abrir el terminal y escribir:
csrutil disable
Reiniciar.
Volver a arrancar en modo seguro y en el terminal escribir lo siguiente. Esto es para que permita escribir un snapshot y que persistan los cambios que realicemos en el sistema:
csrutil authenticated-root disable
Ahora sí, reiniciamos y arrancamos nuestro equipo en modo normal.
Una vez haya arrancado, necesitamos localizar e identificar el disco principal del sistema. Por tanto, abrimos Terminal y ejecutamos:
diskutil list
Montar el disco principal, en mi caso, disk1s5
diskutil mount disk1s5
Mirar con qué nombre se ha montado haciendo mount, seguramente sea el nombre del volumen de siempre pero terminado en “ 1”. Por ejemplo, MacOS 1 (con el espacio y el uno)
Si no lo monta, volver a ejecutar. A mí me ocurrió una vez que tuve que ejecutar dos veces.
Ahora, montamos el volumen en en modo escritura para poder actuar sobre él:
sudo mount -uw /Volumes/MacOS\ 1
Creamos el directorio donde guardaremos un backup del kext. Los ficheros kext son los drivers de MacOS X, hay muchísimos. A nosotros nos interesa el de nombre IOPlatformPluginFamily.kext.
sudo mkdir /Volumes/MacOS\ 1/Users/Shared/backup_IOPLatformPluginFamily
Copiamos el fichero
rsync -av /Volumes/MacOS\ 1/System/Library/Extensions/IOPlatformPluginFamily.kext /Volumes/MacOS\ 1/Users/Shared/backup_IOPLatformPluginFamily/
Eliminamos el kext.
sudo rm -r /Volumes/MacOS\ 1/System/Library/Extensions/IOPlatformPluginFamily.kext
Creamos el snapshot. Esta es la forma de persistir el cambio que hemos hecho en el Sistema Operativo.
sudo /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -s "SinIOPlatform" -v /Volumes/MacOS\ 1
Una vez ejecutado el comando, nos dirá algo de este estilo:
Attempting creation of snapshot SinIOPlatform on volume: /Volumes/MacOS 1
Ahora, configuramos el snapshot como principal, para que al arrancar el sistema, coja ésta versión que acabamos de crear.
sudo /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -r "SinIOPlatform" -v /Volumes/MacOS\ 1
Nos dará el siguiente resultado:
Attempting tagging of snapshot SinIOPlatform on volume: /Volumes/MacOS 1
Una vez finalizado, podemos reiniciar. Ojo, porque como «daño colateral», el arranque puede llevarle minutos (hasta cinco…). Desconozco el motivo, probablemente porque tiene que cargar una snapshot nuestra. Finalmente arranca, no te preocupes, espera.
A mí esto no me preocupa, porque no suelo apagar nunca el portátil. Le bajo la tapa o lo suspendo.
Atención, no volver a activar authenticated-root, porque si no se elimina el snapshot que hemos creado nosotros.
Cómo verificar si los cambios han surtido efecto tras un reinicio:
ls /System/Library/Extensions/ | grep IOPlatformPluginFamily.kext
Debería de devolver vacío.
Quiero agradecer a la fuente sobre la que me he basado, que es la siguiente: https://grafxflow.co.uk/blog/mac-os-x/delete-ioplatformpluginfamilykext-macos-big-sur
