Si llegaste aquí desde un buscador: el arreglo es una línea y está al final. El razonamiento que hay en medio es la parte que vale la pena leer, porque esta clase de fallo va a seguir pasando.
El síntoma
La historia empieza casi siempre en el mismo lugar: el App Center de la consola. Le das a instalar UniFi Access, la interfaz se queda un rato trabajando y la aplicación nunca aparece. Lo intentas de nuevo y pasa lo mismo. Ningún mensaje de error, ningún código que buscar, nada.
Si eso es lo que estás viendo, el dato importante es este: desde la interfaz no hay nada que puedas hacer. Ni reintentar, ni reiniciar la consola, ni esperar a la próxima versión. El fallo y el arreglo viven una capa más abajo, y ahí se llega por SSH.
Llegar a la terminal
SSH viene apagado. En UniFi OS 5.1.31 el interruptor está en los ajustes: en el menú lateral, bajo el nombre de tu consola, entra en Control Plane; quédate en la pestaña Console y baja casi hasta el final, donde aparece SSH. Actívalo y define una contraseña. Ojo con esto: la contraseña es la que fijas ahí, no la de tu cuenta de Ubiquiti. Y el usuario siempre es root.
ssh [email protected] # la IP de tu consola en la LAN
Todo lo que sigue en este artículo ocurre dentro de esa sesión, como root. Cuando termines, apaga SSH otra vez.
Una vez dentro, los registros viven en /data/unifi-core/logs/. En vez de adivinar en qué archivo cae el fallo, pásale grep al directorio completo:
grep -hiE \
'failed to fetch|exit with error|install failed' \
/data/unifi-core/logs/*.log | tail -25
La instalación de aplicaciones la lleva el agente de UOS, así que lo más probable es que caiga en uos-agent.log, pero el grep del directorio te ahorra tener que saberlo. Esto es lo que sale:
Lo que aparece en los registros:
ERROR E: Failed to fetch
https://security.debian.org/debian-security/pool/updates/main/m/mariadb-10.5/
mariadb-common_10.5.29-0%2bdeb11u1_all.deb
404 Not Found
ERROR E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
ERROR Exit with error: Failed to install Debian package: ExitCode Some(100)
INFO Install failed, will attempt to clean up state and retry
El bucle de reintentos es la pista. La consola intenta, falla y vuelve a intentar, sin avisarle a nadie. Y que el fallo se repita a intervalos es en sí una confirmación: estás ante una instalación atascada, no ante un error puntual.
Lo vi con UniFi OS 5.1.31 y Access 4.3.7, en una UDM Pro y en una UNVR4. El modelo de consola no es la variable que importa aquí.
Lo que no lo arregla
Hay dos movimientos obvios, los dos equivocados, y conviene entender por qué para no perder una hora en ellos.
Refrescar el índice de paquetes
El propio mensaje de error sugiere apt-get update. No ayuda:
De la consola:
# apt-get update
Hit:1 https://security.debian.org/debian-security bullseye-security InRelease
Hit:2 https://deb.debian.org/debian bullseye InRelease
Hit:3 https://archive.debian.org/debian bullseye-backports InRelease
Hit:4 https://deb.debian.org/debian bullseye-updates InRelease
Reading package lists... Done
Cuatro líneas Hit. Los índices están al día. El problema no es un índice viejo: es que el índice describe con precisión un archivo que ya no existe:
De la consola:
# apt-cache policy mariadb-common
mariadb-common:
Installed: (none)
Candidate: 1:10.5.29-0+deb11u1
Version table:
1:10.5.29-0+deb11u1 500
500 https://security.debian.org/debian-security bullseye-security/main arm64
1:10.5.23-0+deb11u1 500
500 https://deb.debian.org/debian bullseye/main arm64
La versión candidata es real, está publicada y un índice vigente la referencia. El .deb que había detrás fue retirado del repositorio.
Actualizar el firmware
El segundo instinto es que esto estará arreglado en una versión más nueva. No lo está, porque no hay versión más nueva:
De la consola:
# grep 'Latest available version' /data/unifi-core/logs/firmware.log | tail -1
... "version":"v5.1.31+5acc35d" ...
# cat /usr/lib/version
UNVR4.al324.v5.1.31.5acc35d.260819.1714
La versión instalada y la última disponible son la misma cadena. No hay nada a lo que actualizar.
Y la razón de que el problema exista se ve un comando más tarde:
De la consola:
# grep -i version /etc/os-release
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
El firmware actual está construido sobre Debian 11, que hoy es oldoldstable. Ubiquiti no ha movido su base, y Debian siguió adelante.
La causa raíz, y el detalle que cambia el arreglo
La lectura directa es «bullseye llegó al final de su vida, están desmontando el archivo, todo va a romperse». Esa lectura es incorrecta, y si actúas a partir de ella vas a hacer más trabajo del necesario.
Mira lo que sí se instaló cuando el bloqueo se destrabó. La línea sale de /var/log/dpkg.log, después del arreglo:
De /var/log/dpkg.log:
install libmariadb3:arm64 <none> 1:10.5.29-0+deb11u1
libmariadb3 en la versión 10.5.29, exactamente la que da 404 para mariadb-common, se descargó sin quejarse. Esto no es un desmantelamiento masivo: es un solo archivo ausente del repositorio mientras sus hermanos siguen intactos.
La distinción importa. Si bullseye de verdad hubiera desaparecido, el arreglo sería reapuntar sources.list a archive.debian.org: invasivo, cambia la configuración de un equipo del fabricante y hay que revisarlo después de cada actualización de firmware. Como es un solo paquete, el arreglo puede ser mucho más pequeño.
La tabla de versiones de arriba ya contiene la respuesta. Hay un mariadb-common más viejo, la versión 1:10.5.23-0+deb11u1, esperando en deb.debian.org/debian bullseye/main. Confirma que de verdad se puede descargar antes de comprometerte con nada:
apt-get install -y --download-only \
'mariadb-common=1:10.5.23-0+deb11u1'
Salida real de este comando:
Get:1 https://deb.debian.org/debian bullseye/main arm64
mariadb-common all 1:10.5.23-0+deb11u1 [37.2 kB]
Fetched 37.2 kB in 0s (362 kB/s)
Download complete and in download only mode
37 kB, sin errores.
Medir el impacto antes de instalar
Antes de instalar una versión fijada en un equipo en producción, mira lo que apt piensa hacer, no lo que esperas que haga:
apt-get install -s 'mariadb-common=1:10.5.23-0+deb11u1'
Salida real de este comando:
The following NEW packages will be installed:
mariadb-common mysql-common
0 upgraded, 2 newly installed, 0 to remove and 7 not upgraded.
Dos paquetes nuevos. Nada actualizado, nada eliminado. Esa última parte importa más de lo que parece, porque unifi-access declara una dependencia de jq, y estas consolas traen un jq 1.6~ubnt compilado por Ubiquiti, no el de Debian. Reemplazar la compilación propia del fabricante en su propio equipo es justo el tipo de cambio que produce un fallo inexplicable tres semanas después.
Aquí no pasa. La dependencia está declarada sin restricción de versión:
De la consola:
# dpkg-deb -f /data/uos/downloads/unifi-access_*.deb Depends
ulp-go (>= 1.3.26+1924), jq, ms, coturn, unifi-user-assets (>= 0.6.5)
Un jq sin versión se satisface con lo que ya está instalado, así que la compilación del fabricante se queda. Vale la pena verificarlo en lugar de asumirlo, porque apt list --upgradable muestra jq como actualizable con toda naturalidad y te lleva a la conclusión contraria.
Fíjate también en lo que no está en esa lista de dependencias: mariadb-common no aparece. Llega de forma transitiva, varios niveles más abajo. Eso significa que esta misma clase de fallo puede volver a aparecer por otro paquete, y la parte reutilizable es el camino de diagnóstico de arriba, no el número de versión concreto.
El arreglo
apt-get install -y 'mariadb-common=1:10.5.23-0+deb11u1'
Después reintenta la instalación de Access desde la interfaz de la consola. El resto de la cadena avanza sin más intervención:
Estado final de los paquetes:
unifi-access 4.3.7+12090 [install ok installed]
unifi-user-assets 0.6.5+753 [install ok installed]
unifi-face-shared-lib 1.1.2+160 [install ok installed]
coturn 4.5.2-3 [install ok installed]
Es reversible con apt-get remove mariadb-common mysql-common. Y a propósito no lo fijé con apt-mark hold: el día que Debian publique un mariadb-common más nuevo, o reponga el archivo que falta, apt lo actualizará con normalidad y este parche se deshace solo.
Comprobar que no rompiste nada
Dos comprobaciones, porque la obvia da una falsa alarma.
dpkg --audit reporta varios paquetes sin su archivo de control de md5sums. En UniFi OS son paquetes de la propia Ubiquiti (ulp-go, ucs-agent, node20, node24, uid-agent, ai-feature-controller) y lo reportan desde antes de que toques nada. Es un atajo de empaquetado del fabricante, no una corrupción que hayas introducido tú.
La comprobación que sí dice algo:
dpkg-query -W -f='${Package} ${Status}\n' |
grep -v 'install ok installed'
Salida vacía significa que todos los paquetes están completamente configurados. Si en cambio revisas /var/log/dpkg.log, espera encontrar bastantes líneas half-configured: son estados de transición normales del ciclo de vida de dpkg, no errores, y filtrar por half- te va a convencer de que algo anda mal cuando no es así.
Lo que queda cuando este bug se olvide
La pregunta interesante no es cómo instalar un paquete. Es por qué un equipo vigente, con todo al día y con soporte del fabricante, no podía instalar una aplicación del propio fabricante.
La respuesta es que el firmware y la distribución que lleva debajo envejecen con relojes distintos. Ubiquiti publica 5.1.31 como versión actual. Debian 11 llegó a oldoldstable hace tiempo y sus repositorios se están depurando. Nada está roto desde el punto de vista de ninguna de las dos partes, y el fallo vive justo en la costura entre ambas.
En la práctica, esto significa dos cosas cuando administras equipos cerrados de fabricante y no servidores.
Revisa la distribución base, no solo la versión del firmware. Un cat /etc/os-release en un dispositivo del que vas a depender toma cinco segundos y te dice cuánto margen le queda al fabricante antes de que esto te empiece a pasar de manera rutinaria.
Y cuando el instalador de un fabricante falle por una dependencia, resiste el instinto de reapuntar los repositorios. Lee primero la tabla de versiones. La diferencia entre «esta distribución ya no está» y «este archivo ya no está» es la diferencia entre un cambio de todo el sistema que vas a mantener para siempre y un solo paquete fijado que se quita con un comando.
Espero ver más casos como este, no menos.
Escribí esto después de encontrármelo en la consola de un cliente, y lo verifiqué en una UDM Pro y en una UNVR4 con UniFi OS 5.1.31. Si chocaste con el mismo muro y esto te ahorró la tarde, para eso lo escribí.
Seguir leyendo en IT Rafa
- Repositorios sin suscripción en Proxmox VE, otro caso de pelearse con los repositorios apt de un fabricante
- Instalar Uptime Kuma con Docker, para enterarte de estos fallos por una alerta y no por un tique
- Cómo instalar Docker y Docker Compose en Linux