¿Falló la instalación de Magisk? Diagnostica la imagen de arranque antes de borrar datos

Un dispositivo que no arranca tras flashear Magisk es un problema de diagnóstico, no de restablecimiento. Lo causan habitualmente seis cosas, el síntoma que viste suele reducirlas a una o dos y ninguna se arregla borrando tus datos. Recorre la tabla de descarte de abajo antes de plantearte nada destructivo.

Las seis causas posibles

Son candidatas, no veredictos. Puede haber más de una a la vez, y cuál es la responsable depende de tu dispositivo, de tu compilación de firmware y de lo que flasheaste.

1. Una imagen de arranque de otra compilación. La imagen procede de un firmware que no coincide con el instalado en el dispositivo, aunque sea por un solo nivel de parche de seguridad.
2. Parcheaste la partición equivocada. En algunos dispositivos el ramdisk está en boot y en otros en init_boot. Parchear la que no es deja un dispositivo que no arranca.
3. No se cumplió un requisito de arranque verificado o de vbmeta. La cadena de verificación del dispositivo rechazó la imagen modificada, o el estado de vbmeta no coincide con lo que se flasheó.
4. El bootloader está bloqueado, o se volvió a bloquear. Un bootloader bloqueado no carga una imagen de arranque modificada, y flashear contra uno bloqueado da sus propios errores.
5. El slot equivocado. En dispositivos A/B, la imagen fue al slot inactivo, o el slot activo cambió entre una operación y otra.
6. Un conflicto con un módulo o posterior al arranque. El parche funcionó, el dispositivo arrancó y algo que se ejecuta después del arranque lo tumbó.

Fíjate en lo que no aparece en esa lista: tus datos de usuario. Ninguna de estas seis causas se origina en la partición de datos, y ninguna se soluciona borrándola.

Tabla de descarte de causas

Busca la fila que coincide con lo que realmente observaste.

Esa tabla hace lo que una lista numerada de soluciones no puede: el síntoma reduce las candidatas antes de que pierdas una hora con la equivocada.

Coincidencia exacta de compilación

Esta es la causa a la que más tiempo merece la pena dedicar, porque es la más fácil de hacer mal creyendo que la hiciste bien.

Una imagen de arranque parcheada se deriva de una compilación de firmware concreta. La fuente correcta es el firmware de tu número de modelo exacto y de tu número de compilación exacto, que incluye el nivel de parche de seguridad. No el mismo modelo de teléfono de otra región. No el mismo número de versión de hace un mes. La compilación exacta que está instalada ahora en el dispositivo.

Dónde se suele fallar:

• Variantes de modelo. Un mismo nombre comercial suele cubrir varias variantes de hardware distintas con firmware distinto. Una versión Snapdragon y una Exynos del mismo teléfono son dispositivos diferentes a estos efectos. Las variantes de operador son otro caso aparte.
• Región. El firmware del mismo modelo cambia según la región, y las imágenes no son intercambiables.
• Desfase de compilación. El dispositivo recibió una actualización después (o antes) de que descargaras el firmware. Lo que cuenta es el número de compilación que tiene el dispositivo.
• Subidas reempaquetadas. Una imagen de un servicio de alojamiento de archivos es una incógnita. Usa la distribución del propio fabricante y verifica las sumas de comprobación cuando estén publicadas.

Comprueba la compilación instalada en Settings, en About phone, antes de descargar nada. Si el dispositivo no arranca, puede que el número de compilación se vea en el bootloader o en la pantalla del modo de descarga. Hazle una foto.

Nuestra lista de dispositivos compatibles con root indica qué variantes de qué modelos tienen una vía de root que funciona y dónde están las trampas de las variantes.

boot.img e init_boot.img no son intercambiables

Esto sorprende a quien ya ha hecho root con éxito antes, porque la regla cambió en el transcurso de la historia de Android.

La documentación del Android Open Source Project describe el cambio directamente: los dispositivos que salen con Android 13 tienen una imagen init_boot nueva que contiene el ramdisk genérico, mientras que los que se actualizaron de Android 12 a Android 13 mantienen la misma arquitectura que tenían en Android 12.

La regla práctica que se deduce:

La trampa es que un dispositivo con Android 14 hoy puede estar en cualquiera de las dos filas, según con qué saliera de fábrica. La versión de Android instalada ahora no te dice cuál se aplica. Lo que importa es la versión con la que salió el dispositivo.

La propia documentación de instalación de Magisk explica cómo saber cuál se aplica a tu dispositivo y avisa de que hay excepciones en algunos equipos. Léela para tu dispositivo concreto en lugar de deducirlo de la versión de Android de la caja.

Equivocarse aquí produce un flasheo con buena pinta y un dispositivo que no arranca, y por eso esta causa está tan arriba en la lista de descarte.

La cuestión de vbmeta

Android Verified Boot comprueba la integridad de lo que el bootloader está a punto de cargar. Una imagen de arranque modificada no coincidirá con los hashes esperados, y cómo reacciona el dispositivo depende de la implementación del fabricante.

Algunos dispositivos exigen ajustar el estado de verificación para que arranque una imagen modificada. Otros no. En algunos, cambiar ese estado fuerza un borrado de datos en el siguiente arranque como medida de seguridad. Estos comportamientos dependen del dispositivo y no son coherentes entre fabricantes, ni siquiera entre modelos del mismo fabricante.

Esa variabilidad es la razón por la que este artículo no te da un comando de vbmeta para ejecutar. Aplicar indicadores de verificación incorrectos en un dispositivo que no los necesitaba puede costarte los datos, y no aplicar ninguno en uno que sí los exigía produce el bootloop que ya intentas arreglar. Averigua el requisito de tu modelo exacto, en la documentación del fabricante o en una fuente específica del dispositivo, antes de tocar nada.

Aviso de acción destructiva: en algunos dispositivos, flashear vbmeta con la verificación desactivada provoca el borrado completo de los datos de usuario en el siguiente arranque. Es irreversible. Confirma cómo se comporta tu dispositivo antes de ejecutarlo.

Volver a un estado que arranque

Si el dispositivo está en fastboot y tienes la imagen de arranque original correcta para la compilación instalada, restaurarla revierte el cambio. Esa operación escribe solo en la partición de arranque. No toca los datos de usuario.

Los requisitos, en orden:

1. El dispositivo entra en fastboot y un ordenador lo detecta. Si no, empieza por aquí.
2. Tienes la imagen original sin parchear de la compilación instalada exacta, procedente de la distribución del propio fabricante.
3. Sabes en qué partición va, según la tabla de arriba.
4. Sabes qué slot está activo, si el dispositivo usa slots A/B.

Si te falta algo de esto, detente y consigue lo que falta en lugar de improvisar. Flashear una imagen más o menos correcta en una partición más o menos correcta es como un estado recuperable se convierte en uno peor.

Cuando el problema es el módulo

Si se hizo root al dispositivo con éxito, funcionó con normalidad y solo empezó a entrar en bucle tras instalar un módulo, el diagnóstico es sencillo y la solución no implica a la imagen de arranque en absoluto.

Los sistemas de root ofrecen formas de arrancar con los módulos desactivados para poder quitar el culpable. La documentación de Magisk describe una secuencia de teclas durante el arranque que inicia el sistema con los módulos desactivados. KernelSU documenta su propia vía de rescate, que incluye ejecutar su herramienta de línea de comandos desde una shell de recovery para listar, desactivar o desinstalar módulos.

Ambos métodos actúan sobre el directorio de módulos y respetan los datos de usuario. Usa la documentación actual de la solución de root que realmente instalaste, porque este comportamiento ha cambiado entre versiones y las instrucciones antiguas de los foros pueden describir un mecanismo que ya no existe.

Los módulos que se enganchan pronto en el arranque, sustituyen componentes del sistema o modifican propiedades del dispositivo entrañan más riesgo que los que no lo hacen. Nuestra guía de módulos de Magisk indica qué categorías tienen historial de problemas de arranque y qué comprobar antes de instalar.

No todos los fallos tienen solución

Hablemos claro de los límites, porque el resto del artículo es optimista y los límites son reales:

• Si el bootloader se bloqueó con una imagen de arranque modificada ya flasheada, el dispositivo puede negarse a cargar nada y tampoco aceptar flasheos nuevos. Este estado puede ser difícil o imposible de resolver sin herramientas del fabricante.
• Si el flasheo se interrumpió durante la escritura de una partición, el resultado depende de qué partición era y de hasta dónde llegó.
• Si el dispositivo ya no entra en fastboot y no se detecta en ningún modo, estás fuera de lo que cubre este artículo. Lee soft brick vs hard brick para situar el estado.
• Si el fabricante ya no distribuye el firmware original de tu compilación exacta, puede que no sea posible restaurar la imagen exacta, y las alternativas suelen implicar un borrado.

No afirmamos que todo flasheo fallido de Magisk tenga solución. Algunos no la tienen, y lo honesto es decirlo antes de que gastes dinero en averiguarlo.

Preguntas frecuentes

¿Flashear la imagen de arranque original borrará mis datos? Flashear la partición de arranque no toca la partición de datos de usuario. Lo que borra datos es un restablecimiento, un formateo, un indicador de borrado o un cambio del estado de verificación en dispositivos donde eso fuerza un borrado. Fíjate en la operación, no en las palabras tranquilizadoras.

¿Puedo volver a flashear la imagen parcheada y probar otra vez? Reflashear la misma imagen dará el mismo resultado. Si el problema es la imagen, repetirlo no ayuda. Cambia algo concreto según la tabla de descarte y vuelve a intentarlo.

Mi dispositivo arranca, pero Magisk dice que no está instalado. Normalmente significa que el flasheo fue al slot inactivo, o que el dispositivo arrancó desde el otro slot. Comprueba qué slot está activo. También puede significar que el parche se aplicó a la partición equivocada, lo que cubre la sección de boot vs init_boot.

¿Necesito TWRP o un recovery personalizado para arreglarlo? No para restaurar la imagen de arranque, que es una operación de fastboot. Un recovery personalizado es útil en algunos casos de eliminación de módulos, y plantea sus propias dudas de compatibilidad con los diseños de particiones modernos. Nuestra guía de instalación de TWRP explica dónde encaja y dónde no.

¿Es algo específico de Magisk? No. Las imágenes de otra compilación, la confusión de particiones, los requisitos de verificación y los slots que no coinciden afectan a cualquier modificación de la imagen de arranque. Las instalaciones de KernelSU y APatch tropiezan con las mismas categorías de fallo y con la misma lógica de diagnóstico, y los tres enfoques se diferencian en aspectos que conviene entender antes de elegir uno.

¿Debería restablecer de fábrica y empezar de cero? No como primer paso. Ninguna de las seis causas se origina en la partición de datos, así que es improbable que un restablecimiento arregle alguna. Además es irreversible y, en un dispositivo con cifrado basado en archivos, destruye el material de claves junto con los datos. Recorre antes la tabla.

---

Lecturas relacionadas: Arreglar un bootloop sin perder datos · Qué significa cada síntoma en la pantalla de arranque · Soft brick vs hard brick · Dispositivo no detectado en fastboot · Módulos de Magisk imprescindibles

Fuentes: Android Open Source Project, documentación de la partición de arranque genérica. Documentación oficial de instalación de Magisk. Documentación oficial de rescate de KernelSU.

Última verificación: 24 de agosto de 2026. Los diseños de particiones, los requisitos de arranque verificado y los procedimientos de flasheo varían según el fabricante, el modelo y la compilación. Confirma con la documentación oficial de tu dispositivo antes de ejecutar cualquier comando.