OTA fallida con root: diagnostica antes de reflashear

Una OTA rechazada en un teléfono con root suele ser el motor de actualizaciones funcionando correctamente. Comprobó las particiones que iba a actualizar, las encontró modificadas y se detuvo. Eso es un resultado de verificación, no un daño, y la solución es averiguar qué partición rechazó en lugar de flashear un paquete de firmware completo por encima.

Por qué se negó la actualización

El proceso de actualización de Android verifica el estado actual de las particiones que va a sustituir antes de escribir nada. Si una partición no coincide con lo que espera el paquete de actualización, la actualización se detiene en lugar de dejar un sistema a medio actualizar e impredecible.

El root modifica la cadena de arranque. Ese es todo el mecanismo. Por eso un dispositivo con root presenta justo la discrepancia que esa comprobación está diseñada para detectar.

Conviene interiorizarlo porque cambia el planteamiento del problema. El dispositivo no está roto. No ha fallado nada a nivel de hardware. Algo está modificado, el actualizador lo detectó y se negó. Tu tarea es identificar qué.

Ten en cuenta también que las particiones pueden estar modificadas sin que el root sea el culpable. Un recovery personalizado al que se permitió modificar el sistema, una app con root que cambió un archivo del sistema o un resto de una modificación anterior producen el mismo rechazo aunque el root se quitara hace tiempo.

Primero: ¿qué esquema de particiones usa tu dispositivo?

Esto determina casi todas tus opciones y es la primera pregunta que hay que responder.

Los dispositivos A/B mantienen dos copias de las particiones relevantes. Las actualizaciones se instalan en el conjunto inactivo mientras sigues usando el activo, y el dispositivo cambia de uno a otro al reiniciar. Es el modelo de actualización sin interrupciones.

Los dispositivos no A/B tienen una sola copia. La actualización se aplica a las particiones que estás usando, normalmente a través del recovery.

No hay un atajo fiable para saber cuál tienes a partir del nombre comercial. Comprueba el esquema de particiones en el propio dispositivo o consulta la documentación del fabricante para tu modelo exacto. Equivocarte aquí te lleva por un procedimiento que no corresponde.

La diferencia práctica:

Las causas posibles

Son posibilidades. Cuál se aplica depende de tu dispositivo y de lo que hayas instalado.

1. Una imagen de arranque modificada. El caso más directo. El root parcheó la cadena de arranque, el actualizador la comprobó y no coincidía.

2. Nunca se hizo copia de las imágenes originales. Las herramientas de root pueden restaurar las imágenes originales antes de una actualización, pero solo si existe una copia. Si el dispositivo se rooteó flasheando directamente una imagen ya parcheada, en lugar de usar el flujo de instalación de la propia herramienta, puede que no haya nada desde donde restaurar y el paso de restauración fallará.

3. Una partición del sistema modificada. Un recovery personalizado al que se permitió modificar el sistema, o una app con root que escribió en él, deja un cambio que el actualizador detectará. Este caso persiste después de quitar el root y confunde mucho, porque la gente quita el root, vuelve a intentarlo y obtiene el mismo rechazo.

4. Módulos que interfieren. Los módulos que alteran el comportamiento o los archivos del sistema pueden afectar a la verificación o al arranque posterior a la actualización.

5. Estado de los slots. En los dispositivos A/B importan tanto el slot activo en el momento de la actualización como el slot al que apuntaba la actualización. También importa si una actualización anterior dejó los slots en un estado inesperado.

6. Estado del recovery. Un recovery personalizado en lugar del original cambia lo que ocurre cuando la actualización intenta usarlo.

El orden del diagnóstico

Repasa esto antes de tocar un paquete de firmware.

Lee el fallo

Anota el error exacto, en qué punto del proceso falló y si el dispositivo reinició después en recovery. Una actualización que falla durante la descarga es un problema distinto de una que falla durante la verificación, y distinto también de una que se instala y luego no arranca.

Si ahora el dispositivo no arranca, en lugar de limitarse a no actualizarse, para aquí y pasa a qué significa cada síntoma de arranque, porque estás en otra situación.

Averigua qué está modificado

Antes de poder devolver algo al estado original, necesitas saber qué no es original. Boot, y en dispositivos más nuevos posiblemente una imagen aparte con el ramdisk, es lo evidente. System es lo que más se olvida. Recovery, lo segundo que se olvida.

Si no instalaste tú las modificaciones, o heredaste el dispositivo, da por hecho que no lo sabes y trata todas las causas como posibles.

Restaura antes de actualizar, no después

La propia documentación de Magisk describe directamente el flujo previsto: restaura las imágenes originales desde la copia que Magisk hizo al instalarse, para que pase la verificación previa a la actualización, y en concreto no reinicies después de restaurar, porque reiniciar en ese momento completa una desinstalación. Entonces el dispositivo acepta la actualización con normalidad y el root se vuelve a aplicar después por la vía documentada.

Lee la documentación actual de la solución de root que hayas instalado, y léela para el esquema de particiones de tu dispositivo. Este flujo ha cambiado entre versiones, y las diferencias entre el manejo de A/B y no A/B son importantes. Unas instrucciones de un hilo antiguo de un foro pueden describir un mecanismo que ya no existe.

La documentación de Magisk también reconoce con franqueza que en dispositivos no A/B no existe un método sin interrupciones y que el root habrá que volver a aplicarlo manualmente con un ordenador después. Conviene saberlo antes de empezar y no descubrirlo a mitad del proceso.

Ten a mano las imágenes originales correctas

Si falta la copia de la herramienta de root, necesitas las imágenes originales de tu modelo exacto y de tu compilación actual exacta, de la distribución del propio fabricante. No una versión parecida. No de otra región. Acertar con la compilación es donde más se falla, y el resultado es un dispositivo que se flashea sin problemas y no arranca.

Cómo volver a un estado de arranque cuyo buen funcionamiento está confirmado

Si el dispositivo todavía arranca, tienes tiempo y opciones. Aprovéchalos.

Si el dispositivo ya no arranca tras el intento, la prioridad pasa a ser recuperar un estado arrancable, y en un dispositivo A/B lo primero que hay que mirar es el otro slot. Que contenga algo útil depende de tu historial de actualizaciones, pero comprobarlo no cuesta nada y no destruye datos.

Restaurar la imagen de arranque original correcta escribe solo en la partición boot. No toca los datos del usuario. Esa es la operación que quieres. Un flasheo completo de firmware es otra operación con otras consecuencias, que se explican más abajo.

El riesgo para los datos, sin rodeos

Nada del diagnóstico anterior toca los datos del usuario. Esto sí:

La trampa es el script de flasheo del fabricante que incluye por defecto un paso de borrado. La gente lo ejecuta para reparar una actualización fallida y pierde todo lo que hay en el dispositivo. Abre el script y léelo. En un dispositivo con cifrado basado en archivos, el borrado elimina el material de claves junto con los datos, así que después no hay recuperación posible. Nuestra guía de bootloop sin pérdida de datos explica por qué eso cambia la secuencia que debes seguir.

Si el dispositivo contiene datos de los que no tienes copia, haz la copia ahora, mientras todavía arranca. Este es el momento, y no vuelve.

Por qué no existe una secuencia universal

Cada fabricante implementa las actualizaciones de forma distinta. El modelo de flasheo de Samsung no es el de Google. El de Xiaomi no es el de OnePlus. Y los dispositivos de una misma marca cambian según la generación, la región y la variante del operador.

Por eso este artículo te da las categorías y el orden en que pensar, no una lista de comandos. Una lista de comandos sería incorrecta para algunos lectores de un modo que les costaría los datos, y no hay manera de escribir una que sea segura para toda la gama.

Busca el procedimiento concreto para tu modelo y compilación exactos, en el fabricante o en una fuente mantenida específica del dispositivo. Nuestra lista de dispositivos rooteables muestra dónde son más marcadas las diferencias por marca.

Preguntas frecuentes

¿Puedo saltarme la actualización? Puedes, y en una versión suelta es una decisión razonable. Con el tiempo acumulas parches de seguridad perdidos y la distancia entre tu compilación y el firmware actual se agranda, lo que hace la actualización final más difícil, no más fácil.

¿Quitar el root lo arregla? A veces sí y a veces no, y eso es lo que confunde. Si solo se modificó la cadena de arranque, restaurarla resuelve la discrepancia. Si también se modificó la partición del sistema o el recovery, quitar el root deja esos cambios y la actualización sigue rechazándose.

Mi teléfono se actualizó pero perdió el root. ¿Es un fallo? No, es uno de los resultados documentados, sobre todo en dispositivos no A/B. La actualización se completó y la modificación fue sustituida. Vuelve a rootear después por la vía habitual con las imágenes de la nueva compilación.

La actualización se instaló y ahora no arranca. Es otro problema, y más urgente. Ve a qué significa cada síntoma de arranque y, si el dispositivo acaba en recovery, a qué comprobar cuando sigue arrancando ahí. No hagas un reset.

¿Debo usar una utilidad de reparación del fabricante? Esas herramientas suelen descargar el firmware original y flashearlo, lo cual es legítimo. Lo que importa es si ese flasheo conserva los datos del usuario en tu dispositivo concreto, y eso lo determinan el firmware y el modo, no la interfaz de la herramienta. Compruébalo antes de ejecutarla.

¿Merece la pena seguir con root si las actualizaciones fallan una y otra vez? Es una decisión de criterio sobre lo que te aporta el root. Nuestro análisis honesto de los riesgos de rootear cubre ese equilibrio, incluida la fricción con las actualizaciones, que es un coste continuo y no puntual.

---

Lecturas relacionadas: Fallo al flashear Magisk · Arreglar un bootloop sin perder datos · Android arranca siempre en recovery · Errores FAIL de Odin en Samsung · Módulos esenciales de Magisk

Fuentes: documentación oficial de Magisk sobre actualizaciones OTA. Documentación del Android Open Source Project sobre actualizaciones del sistema A/B.

Última verificación: 19 de agosto de 2026. Los mecanismos de actualización, los esquemas de particiones y los procedimientos de flasheo de los fabricantes varían según el modelo, la región y la compilación. Confírmalo en la documentación oficial de tu dispositivo.