Usar Codex para ayudar a actualizar un Redmi AX6000 a ImmortalWrt 25.12.0

Prefacio

El dispositivo de esta actualización fue un Redmi AX6000 con ImmortalWrt. La versión inicial era 24.10.6 y la versión objetivo era 25.12.0.

Lo más digno de registrar no fue solo la actualización, sino la forma de colaboración. No flasheé el firmware por pura experiencia; hice que Codex participara durante todo el proceso. Primero inventarió los hechos del dispositivo, la versión objetivo, el cambio de sistema de paquetes, el alcance de la copia de seguridad, los pasos de actualización y la verificación de recuperación. Después revisé el plan; una vez confirmado que no había problemas, Codex continuó ejecutando lo que podía ejecutar, y yo decidí la siguiente instrucción según sus salidas.

El resultado fue bueno. Tras la actualización, LAN, Wi-Fi, LuCI, OpenClash, WireGuard y DDNS volvieron a la normalidad. La ventana en la que realmente tuve que intervenir manualmente fue breve: después de la actualización restauré primero la red proxy de OpenClash; luego Codex retomó WireGuard, DDNS, verificación de servicios y ordenación de documentación.

Este artículo es el repaso de esa actualización.

¿Por qué dejar que un Agent ayude a actualizar un router?

Actualizar un router no es como actualizar software ordinario. Si falla, rara vez basta con “volver a ejecutar un comando”: puedes perder SSH, DNS, salida a internet, e incluso interrumpir la operación remota porque el propio router que estás actualizando forma parte del canal de control.

Lo que quería que Codex hiciera era dividir la actualización en varias preguntas que había que responder con claridad:

1. ¿Cuál es exactamente el profile del dispositivo actual?
2. ¿En qué estado están la versión, el kernel, el gestor de paquetes, los repositorios y los paquetes instalados?
3. ¿El firmware objetivo soporta realmente este dispositivo?
4. ¿El sistema de paquetes de 25.12.0 todavía permite instalar el software del que dependo?
5. ¿Qué configuraciones deben entrar en la copia de seguridad de sysupgrade y qué datos runtime deben respaldarse por separado?
6. ¿Cómo salir temporalmente del DNS de OpenClash antes de actualizar?
7. ¿Cuál debe ser el orden para restaurar paquetes, servicios, DNS, WireGuard y DDNS después de actualizar?
8. Si un paso falla, ¿dónde detenerse y cómo evitar ampliar el riesgo?

Este tipo de preguntas encaja bien con un Agent. Puede unir, sin cansarse, los hechos del sistema actual, el directorio oficial de releases, la imagen objetivo, la lista de paquetes, el contenido de la copia de seguridad y los comandos de verificación, hasta formar una checklist ejecutable.

El flujo ideal es: Codex propone el plan, yo lo reviso; tras aprobarlo, Codex ejecuta comandos, lee salidas y sugiere el siguiente paso; yo me concentro en juzgar si el plan es razonable, si los resultados cumplen lo esperado y si conviene continuar o detenerse.

Esta vez no logré que Codex lo ejecutara todo por completo debido a mi entorno de red. Codex accede a internet mediante el proxy de OpenClash, y OpenClash corría precisamente en el router que estaba actualizando. Después de la actualización, antes de recuperar el proxy, tuve que cerrar manualmente el ciclo mínimo: actualizar el índice apk, instalar OpenClash y restaurar la red proxy. Después devolví a Agent el diagnóstico, la verificación y la documentación.

Entorno actual y versión objetivo

Estado del dispositivo antes de actualizar:

设备: Xiaomi Redmi Router AX6000
board: xiaomi,redmi-router-ax6000-ubootmod
target: mediatek/filogic
arch: aarch64_cortex-a53
当前版本: ImmortalWrt 24.10.6
当前内核: 6.6.133
包管理器: opkg
root shell: /bin/bash

Versión objetivo:

目标版本: ImmortalWrt 25.12.0
目标内核: 6.12.87
包管理器: apk
目标镜像: xiaomi_redmi-router-ax6000-ubootmod-squashfs-sysupgrade.itb

El punto más importante aquí es ubootmod. El Redmi AX6000 tiene distintos layouts. No se puede elegir una imagen mirando solo el nombre comercial “AX6000”; hay que hacer coincidir la imagen sysupgrade correspondiente a xiaomi,redmi-router-ax6000-ubootmod.

Otro punto clave es que 25.12.0 no es una actualización menor ordinaria. Cruza la frontera del sistema de paquetes: migra de opkg a apk. Esto significa que la lógica de recuperación tras la actualización ya no puede seguir usando los hábitos de /etc/opkg/distfeeds.conf, customfeeds.conf y paquetes .ipk.

¿Qué hace atractiva a 25.12.0 frente a 24.10.6?

Para mí, el atractivo de 25.12.0 viene principalmente de tres cosas: nuevo kernel, nuevo sistema de paquetes y hábitos personales de mantenimiento.

Primero, el kernel. Mi 24.10.6 corría sobre kernel 6.6.133; 25.12.0 corresponde a kernel 6.12.87. Un router no necesita perseguir cada kernel nuevo, pero una nueva rama de kernel suele significar que drivers, stack de red, correcciones de seguridad y ecosistema kmod entran en una línea de mantenimiento más reciente. Si el profile del dispositivo y los paquetes clave son compatibles, eso por sí solo ya es una razón razonable para actualizar.

Segundo, el gestor de paquetes. La serie OpenWrt 25.12 cambia el gestor predeterminado de opkg a apk. opkg ha sido la solución tradicional de OpenWrt durante años, pero su mantenimiento a largo plazo y su capacidad de resolución de dependencias ya se veían débiles; apk, procedente del ecosistema Alpine, sigue activo y ofrece una experiencia más moderna en índices, dependencias y comandos.

Desde el mantenimiento diario, el cambio más directo es:

• Los repositorios migran de distfeeds.conf a /etc/apk/repositories
• Instalación, consulta, actualización y eliminación cambian a sintaxis apk
• Al diagnosticar paquetes, hay que mirar índices de repositorio apk y comandos apk, no seguir leyendo el estado de opkg

Tercero, mi preferencia personal: la infraestructura puede ser estable, pero no debe quedarse demasiado atrás durante mucho tiempo. Antes posponía estas actualizaciones por pasos tediosos y alto coste de fallo; esta vez, con un Agent, inventario, comparación, lista de backups, orden de recuperación y comandos de verificación pudieron quedar en manos de Codex, lo que redujo notablemente la carga.

24.10.6, como service release de la serie 24.10, sigue siendo adecuada para mantenimiento estable; 25.12.0 es el punto de partida de una nueva rama estable. Para infraestructura como un router, una nueva rama no significa automáticamente que sea mejor. Mi juicio esta vez fue: el profile está claramente soportado, los paquetes clave se pueden restaurar desde repositorios oficiales, y los riesgos de DNS y OpenClash son controlables; por tanto, el beneficio supera el coste de mantenimiento.

Comprobaciones obligatorias antes de actualizar

Esta es la parte más importante de todo el plan. El riesgo de una actualización de firmware suele quedar sembrado antes de ejecutar sysupgrade: si se juzga mal el profile, el alcance del backup, la cadena DNS, los repositorios o el orden de recuperación, todo lo posterior será pasivo.

1. Confirmar el profile del dispositivo

Al menos hay que confirmar:

ubus call system board
cat /etc/openwrt_release

Hay que mirar con atención board_name, target, arch y la versión actual. La imagen debe coincidir con ubootmod; no conviene probar suerte con una imagen de layout ordinario.

2. Confirmar espacio de backup y estado de ejecución

df -h / /overlay /tmp
ip route
wifi status

/tmp debe poder contener el firmware, y /overlay debe tener espacio suficiente para procesar backups y configuración temporal. No conviene ejecutar la actualización a través de WireGuard, porque la actualización reinicia el stack de red; lo mejor es operar dentro de la red local.

3. Respaldar configuraciones clave

Dividí el backup en dos tipos.

El primer tipo son las configuraciones que sysupgrade debe conservar, por ejemplo:

/etc/config/network
/etc/config/wireless
/etc/config/firewall
/etc/config/dhcp
/etc/config/ddns
/etc/config/openclash
/etc/config/system
/etc/config/luci
/etc/dropbear/authorized_keys
/etc/passwd
/etc/group
/etc/shadow
/etc/crontabs/root

El segundo tipo son datos runtime que solo conviene respaldar offline y no meter en sysupgrade, como cores, reglas, datos Geo e historial/cache de OpenClash. Son grandes y complejos, y no deberían meterse completos en la lista de conservación del sistema.

4. Reducir el alcance conservado por sysupgrade

Esta fue una de las partes más valiosas del plan de Agent: no conservar todos los directorios que en el sistema antiguo parecen “útiles”.

En particular, hay que evitar:

/etc/opkg
/usr/share/openclash
/etc/openclash 全目录
/data
/www

25.12.0 ya cambió a apk; conservar /etc/opkg solo arrastraría estado histórico del viejo sistema de paquetes. El runtime de OpenClash también debe respaldarse por separado y restaurarse después de actualizar.

5. Salir temporalmente del DNS de OpenClash

Mi cadena DNS original dependía de OpenClash:

dnsmasq -> 127.0.0.1#7874 -> OpenClash

Después de la actualización, si OpenClash aún no se ha restaurado y DNS sigue apuntando a 127.0.0.1#7874, aparece un falso bloqueo: Wi-Fi y WAN están bien, pero los dominios no resuelven.

Por eso, antes de actualizar, primero hay que cambiar DNS temporalmente a un upstream ordinario y confirmar:

nslookup openwrt.org 127.0.0.1

Solo después de resolver correctamente conviene continuar.

6. Cambiar temporalmente el root shell a ash

Mi root shell era /bin/bash. Después de actualizar, si bash aún no está instalado pero /etc/passwd sigue apuntando a /bin/bash, el inicio de sesión SSH puede fallar.

Por eso, antes de actualizar, lo cambié temporalmente a /bin/ash; tras confirmar que bash estaba instalado en el nuevo sistema, volví a cambiarlo.

7. Verificación de hash y compatibilidad del firmware

Después de descargar el firmware, primero se verifica sha256; luego se copia al router y se prueba con:

sysupgrade -T <firmware.itb>

Solo si no aparecen device mismatch, format error ni compat error se debe ejecutar la actualización real.

Riesgos que conviene evitar

No mezclar opkg, ipk y apk

Esta es la frontera más importante de la actualización a 25.12.0.

Después de actualizar, no escribas fuentes .ipk de terceros de 24.10 en /etc/apk/repositories, ni intentes restaurar paquetes antiguos con opkg. Para que un repositorio de terceros pueda usarse en 25.12, al menos debe cumplir:

1. 包文件是 .apk
2. 仓库有 packages.adb
3. arch 是 aarch64_cortex-a53
4. 版本线是 25.12
5. 不混入 24.10/opkg/ipk 包

No tratar OpenClash como un directorio de configuración ordinario

/etc/config/openclash puede conservarse, pero /etc/openclash contiene muchos datos runtime. Mi método fue: la configuración va por sysupgrade; el runtime se empaqueta por separado; después de actualizar se restaura con OpenClash detenido y luego se arranca el servicio.

No restaurar el DNS de OpenClash demasiado pronto

Solo cuando OpenClash ya está iniciado y escuchando en 7874 conviene devolver el upstream de dnsmasq a 127.0.0.1#7874.

No actualizar remotamente a través de WireGuard

WireGuard se reiniciará junto con network y módulos del kernel. Durante la actualización real, no debe usarse como canal de control.

No restaurar paquetes históricos en lote

opkg list-installed puede servir como referencia, pero no se debe instalar todo en bloque después de la actualización. Lo correcto es restaurar únicamente los paquetes clave que se haya confirmado que existen en el repositorio oficial apk de 25.12, y luego verificar los servicios uno por uno.

Cerrar el ciclo del cambio bash/ash para root

Si el root shell apunta a /bin/bash, antes de actualizar es mejor cambiarlo temporalmente a /bin/ash. Cuando el nuevo sistema arranque, bash quizá aún no esté instalado; si /etc/passwd sigue apuntando a /bin/bash, podrías encerrarte fuera de SSH.

En la recuperación hay que comprobarlo en sentido inverso: confirmar que bash está instalado y que /bin/bash existe antes de devolver el root shell a bash.

Reservar una ventana de intervención humana cuando el Agent depende de OpenClash

La limitación de esta vez fue muy concreta: antes de restaurar OpenClash, Codex quizá no podía acceder de forma estable a internet. El plan debía marcar con antelación esta ventana de intervención humana: después de la actualización, una persona ejecuta manualmente apk update, instala OpenClash y restaura el proxy; cuando OpenClash vuelve a la normalidad, la operación regresa al Agent.

Mis dos operaciones especiales esta vez

1. Volver de USTC al repositorio oficial

Antes, por velocidad de red, había cambiado los repositorios al mirror de USTC. Mi intuición antes de actualizar era que seguir usando el mirror sería más rápido.

Pero durante la recuperación descubrí que el mirror de USTC carecía de algunos paquetes clave, especialmente de ciertos paquetes relacionados con una aplicación de proxy. En cambio, los paquetes del repositorio oficial downloads.immortalwrt.org eran más completos y, en mi entorno de red, se podían acceder sin proxy.

Así que el plan final fue: durante la recuperación de 25.12.0 usar solo el repositorio oficial, no USTC y no fuentes de terceros. Primero restaurar el sistema y los servicios clave; después pensar en aceleración por mirror.

Mi /etc/apk/repositories usó fuentes oficiales de 25.12, incluyendo target packages, kmods y base, luci, packages, routing y telephony bajo aarch64_cortex-a53.

2. La única ventana manual: restaurar OpenClash

Después de actualizar, mi operación manual se concentró en restaurar la red proxy:

apk update
apk add luci-app-openclash luci-compat

Después de que OpenClash se recuperó y el proxy estuvo disponible, devolví el resto del trabajo a Codex. Instalación de paquetes de WireGuard, network restart, verificación de interfaces y revisión de logs fueron gestionados por Codex.

Orden de recuperación después de actualizar

El orden final de recuperación se dividió en dos tramos:

1. Recuperación manual del proxy: verificación básica, confirmación de apk y /etc/apk/repositories, uso del repositorio oficial para apk update, instalación de OpenClash y restauración de la red proxy.
2. Cierre por Codex: instalación de bash, WireGuard, DDNS, Argon, bridger y otros paquetes clave; cambio del root shell de vuelta a /bin/bash; restauración de runtime y DNS de OpenClash; reinicio de network; verificación de WireGuard, DDNS, LuCI, acceso de clientes y logs.

La ventaja de este orden es que cada paso tiene condiciones previas claras. DNS no se restaura antes que OpenClash; bash no se usa antes de instalar el paquete; WireGuard no se verifica solo mirando la lista de paquetes, sino también el handler de network y la interfaz real.

apk Quick Reference

Después de 25.12, el mantenimiento diario debe cambiar el hábito de opkg a apk.

Actualizar índice:

apk update

Instalar paquetes:

apk add bash luci-app-openclash wireguard-tools

Buscar paquetes:

apk search openclash
apk search wireguard

Ver paquetes instalados:

apk list --installed
apk list --installed | grep wireguard

Ver información de un paquete:

apk info bash
apk info -a bash

Eliminar paquetes:

apk del <package>

Ver y editar repositorios:

cat /etc/apk/repositories
vi /etc/apk/repositories
apk update

Comparado con opkg, lo que más requiere reconstruir memoria muscular es: no volver a modificar /etc/opkg/distfeeds.conf, no tratar .ipk como paquete instalable y no mezclar repositorios antiguos.

Lo que aprendí al usar un Agent esta vez

Esta actualización me confirmó algo: un Agent puede reducir de forma significativa la carga operativa del mantenimiento de infraestructura. Además de escribir el plan, puede ejecutar muchos pasos tediosos, repetitivos y fáciles de olvidar, dividiendo la actualización en etapas verificables.

Donde realmente ayudó:

• Partir de hechos del dispositivo, sin tomar “AX6000” como único criterio
• Identificar la migración a apk en 25.12.0 como principal frontera de riesgo
• Dividir el backup en configuraciones sysupgrade y datos runtime
• Tratar por adelantado problemas como DNS de OpenClash y bash shell, que pueden dejarte fuera
• Aclarar qué repositorios de terceros no deben migrarse y qué paquetes pueden restaurarse desde fuentes oficiales
• Asignar comandos de verificación a cada etapa
• Ejecutar comandos tediosos, leer resultados y proponer la siguiente ronda según ellos

El papel humano también queda más claro. Ya no necesito gastar atención copiando comandos, ordenando listas de paquetes o buscando rutas repetidamente; puedo concentrarme en revisar el plan, observar salidas clave, juzgar la recuperación y dar al Agent la siguiente instrucción. El avance fue mucho más rápido que haciéndolo todo a mano y el razonamiento se mantuvo más estable.

Mi conclusión es: una actualización de router puede involucrar profundamente a un Agent, pero no conviene convertirla en un script sin supervisión. La forma más estable es que el Agent se encargue de plan, ejecución, verificación y ordenación de información; y que la persona revise, autorice, tome el control cuando la red se interrumpe y juzgue los nodos críticos.

Resumen

Actualizar un Redmi AX6000 de ImmortalWrt 24.10.6 a 25.12.0 es factible, pero esta actualización debe prepararse como una migración opkg -> apk, no como una actualización menor ordinaria.

Las cuatro experiencias más importantes de esta actualización:

1. Confirmar primero el profile ubootmod, el sha256 del firmware y sysupgrade -T
2. Reducir el alcance del backup antes de actualizar, sin arrastrar viejo opkg ni grandes estados runtime
3. Usar primero el repositorio oficial apk después de actualizar, restaurar servicios clave y solo después considerar fuentes de terceros
4. Antes de restaurar OpenClash hace falta intervención humana; después se puede devolver a Codex la gestión de WireGuard, DDNS y verificaciones posteriores

Si también vas a actualizar un dispositivo similar, recomiendo pedir primero al Agent un plan basado en los hechos de tu máquina actual y ejecutarlo punto por punto. No copies directamente comandos de otra persona, y sobre todo no ignores los límites de board profile, repositorios, DNS y plugins de terceros.