RESPUESTA ACTUALIZADA:
Me he dado cuenta de que safe boot (hold shift) Funcionaba bien con la CPU disponible pero limitada por el hecho de no cargar todo.
Entonces hice Justin Silvers método para eliminar los kexts más antiguos. Particularmente, antes de eso, sólo manejaba kexts bajo /Library y ~/Library pero ahora también estaba eliminando los más antiguos de /System/Library .
Uno de los kexts que eliminé fue PACEsupport y también moví otros kexts antiguos relacionados con Mbox2. Estos eran de pre 2015.
Pero esto no arregló las cosas de inmediato y ni siquiera después de reiniciar, pero sí obligó a la caché a reconstruirse desde cero como lo veo hacer en verbose boot mode (cmd+v) .
Así que salí a comprar un cable de repuesto, ya que había renunciado a arreglar el S.O. e iba a intentar que mi viejo disco duro externo restaurara una instantánea antigua si era posible, y de repente, de la nada, volvió a liberar recursos de la CPU y ahora el kernel vuelve a procesar bien y ahora sólo tengo que encontrar la forma correcta de reconocer mi viejo disco duro externo.
En el momento en que liberó recursos parecía estar procesando una gran cantidad de QuickLookSatellite procesos y tomé una instantánea aquí. Como se puede ver el núcleo estaba utilizando toda la CPU (a veces hasta 1300% o más) y aquí se cae del acantilado de nuevo a 18% aparentemente al azar, pero creo que sólo finalmente procesado toda la caché kext de nuevo y tal vez algunos de los kexts eliminados ya no estaban impidiendo que. Pero creo que había varios kexts que eran problemáticos aquí particularmente originalmente el Commander El proceso de desinstalación de kext estaba DDoSing la CPU del kernel.
![enter image description here]()
ACTUALIZACIÓN:
efectivamente el problema volvió. Sin embargo, pude solucionarlo haciendo lo siguiente.
Después de que el proceso de descifrado del disco terminó, todavía no pude reinstalar el S.O. a través del arranque de recuperación, debido a los problemas de conexión con el servidor de Apple, incluso después de arreglar los problemas de sincronización de fecha.
Sin embargo, pude hacer que mi sistema funcionara de nuevo eliminando algunos elementos de inicio y demonios que creo que estaban inundando el uso de la CPU de mi sistema. Encontré estos a través de la inspección de la consola (en la carpeta de utilidad) y mediante el uso de la herramienta EtreCheck.
Efectivamente, un par de kexts antiguos estaban continuamente sondeando mi kernel O.S. (particularmente uno llamado Commander , asociada a un antiguo proceso de desinstalación del dongle WIFI y otra asociada a un antiguo programa llamado NoSleep que impediría que el S.O. durmiera, pero fue diseñado para un S.O. más antiguo).
Estos deben haber estado en conflicto con los cambios del kernel en high sierra + update. Así que estaban efectivamente DDOSing mi O.S y, en consecuencia, la CPU del kernel se inundó. Detener estos y eliminar un montón de kexts innecesarios parece haber arreglado el problema en un O.S funcional de nuevo. No estoy seguro de si fueron sólo esos dos kexts u otros kexts eliminados los que finalmente arreglaron el problema, pero al menos esto te da una idea de qué hacer si tienes el mismo problema.
Recursos:
osxdaily.com/2011/-3/08/remove-an-agent-from-launchd
etrecheck.com
Resultado: Mi tiempo de arranque se hizo más rápido, pero parece que aún no ha vuelto a la velocidad anterior al problema. Sin embargo, el S.O. ahora es completamente funcional de nuevo, con el uso del kernal de la CPU en reposo al mínimo y el uso de la CPU del usuario disponible de nuevo.
Respuesta originalmente aceptada:
extrañamente, usé mi arranque de Windows durante unos días, e incluso hice una actualización de Windows, entonces traté de arrancar Mac de nuevo y su trabajo en su mayoría bien ahora, todavía tomó un poco más lento para arrancar (pero no 20 minutos como antes), y el descifrado ni siquiera ha terminado. terminado ahora. Así que, aparte de no usar el volumen durante unos días, no tengo no tengo ni idea de por qué ahora está funcionando aparentemente bien de nuevo. Sugiero que Si tiene un problema similar a mirar los enlaces que he publicado en el detalles de la pregunta. Tal vez sólo el acceso al sector de arranque con Windows ayudó a arreglar algunos archivos o tal vez fue el último de primeros auxilios que estaba que no lo solucionó inmediatamente, sino que lo solucionó, pero También es posible que el problema no se haya solucionado del todo y que vuelva a aparecer. que el problema no se haya solucionado del todo y vuelva a aparecer, pero por ahora por ahora.
1 votos
¿Usa Windows la encriptación?
0 votos
No lo creo
0 votos
¿Por qué es aceptable para ti usar Window sin encriptación, pero necesitabas encriptación cuando usabas MacOS? ¿Por qué no instalar MacOS sin cifrado y seguir utilizando MacOS?
0 votos
@DavidAnderson Sólo utilizo Windows en contadas ocasiones para el desarrollo de Windows. No tengo ningún dato privado en ese volumen. además, si supiera que el cifrado de la bóveda de archivos podría estropear mi volumen en la actualización, puede que no lo hubiera utilizado en primer lugar.