Errores típicos al actualizar versiones intermedias de Ubuntu

Si acabas de instalar una versión intermedia de Ubuntu y te han dicho que “las actualizaciones pueden romper el sistema”, es normal que estés con la mosca detrás de la oreja. Las versiones no LTS prometen software más reciente, pero también actúan como laboratorio de pruebas, y eso trae dudas razonables: ¿actualizo con tranquilidad o mejor reinstalo cada vez que sale una nueva versión?

En este artículo vamos a desgranar, paso a paso, los errores típicos al actualizar versiones intermedias de Ubuntu (y en general al actualizar Ubuntu), qué los provoca, cómo evitarlos y qué hacer cuando ya es demasiado tarde y algo se ha roto. Además, veremos el caso concreto de la “oxidación” del sistema con Rust, dónde falló Ubuntu 25.10 y por qué, a pesar de los sustos, las versiones intermedias son claves para que las LTS sean rocas. Vamos allá con una guía sobre errores típicos al actualizar versiones intermedias de Ubuntu. 

Versiones LTS vs versiones intermedias: qué riesgo asumes realmente

En el ecosistema Ubuntu conviven dos ritmos de lanzamiento muy claros, y entenderlos es básico para saber qué tipo de problemas te puedes encontrar al actualizar:

• Versiones LTS (Long Term Support): cada 2 años, con 5 años de soporte estándar (y más con Ubuntu Pro).
• Versiones intermedias: salen cada 6 meses y tienen solo 9 meses de soporte.

Las versiones LTS están pensadas para quienes buscan máxima estabilidad a largo plazo: servidores, entornos de trabajo serios, equipos de producción o usuarios que no quieren sorpresas. Mantienen un kernel más conservador y versiones de escritorio y librerías probadas hasta la saciedad.

Las versiones intermedias, en cambio, son el terreno donde Canonical se atreve a introducir cambios profundos en el sistema, nuevos kernels, versiones recientes de GNOME, librerías y, como se ha visto recientemente, hasta reescrituras de herramientas críticas en Rust. Son ideales para quien quiere software más actual, probar novedades o colaborar reportando errores… pero eso implica aceptar que algo puede fallar.

Si usas una versión intermedia como sistema del día a día, es clave entender que:

• Tendrás que actualizar cada 9 meses (aprox.) usando do-release-upgrade, o reinstalar desde cero.
• Los cambios radicales pueden llegar primero aquí, y las posibilidades de encontrar bugs serios son mayores que en LTS.
• Es muy recomendable tener copias de seguridad regulares y cierta tolerancia a trastear con el sistema si algo se rompe.

Para un equipo de uso diario con juegos, máquinas virtuales y trabajo ligero de desarrollo, se puede usar una versión intermedia sin problema, pero con la cabeza fría: no te va a explotar el PC, pero tampoco vas a tener la misma tranquilidad que con una LTS.

El caso Rust en Ubuntu 25.10: cuando el “campo de pruebas” se nota

En una de las versiones intermedias recientes, Ubuntu dio un paso especialmente sonado: empezar a “oxidar” el sistema, es decir, sustituir componentes clave escritos en C por reimplementaciones en Rust, buscando más seguridad y modernización del proceso de construcción del sistema.

Este movimiento incluyó dos cambios muy sensibles: la adopción de uutils coreutils (reimplementación en Rust de las coreutils de GNU) y sudo-rs (un sudo reescrito también en Rust). Y justo ahí aparecieron varios errores que ilustran de maravilla los riesgos de las versiones intermedias.

Qué son uutils coreutils y por qué un bug en “date -r” rompió las actualizaciones

Las coreutils son el corazón de la línea de comandos en cualquier sistema tipo Unix: comandos como ls, cp, rm, mv, date o cat se usan constantemente, incluso si no eres consciente. Sin ellos, la shell prácticamente se queda sin manos.

Tradicionalmente estas utilidades están escritas en C bajo el paraguas de GNU coreutils. El proyecto uutils coreutils las reimplementa en Rust, con el objetivo de ofrecer versiones multiplataforma (Linux, macOS, Windows) y aprovechar la seguridad en memoria del lenguaje. Canonical decidió integrar esta variante en una versión intermedia para ponerla a prueba a gran escala.

El problema gordo vino con el comando date, en concreto con la opción -r. Esta opción sirve para obtener la fecha de última modificación de un archivo, por ejemplo:

date -r /etc/fstab

En la implementación en Rust que llegó a Ubuntu 25.10, el argumento -r estaba bugueado: en lugar de devolver la fecha real de modificación del archivo, devolvía siempre la hora actual del sistema.

Puede parecer una tontería, pero ese pequeño fallo provocó dos efectos muy serios:

• Scripts de copias de seguridad: muchos scripts de backup consultan la fecha de los archivos de copia para decidir si toca crear una nueva. Si date -r dice que siempre son de “hoy”, el script asume que ya se ha hecho la copia y no ejecuta el backup.
• Actualizaciones automáticas “unattended-upgrades”: Ubuntu utiliza esta misma lógica para saber cuándo fue la última comprobación de actualizaciones. Si date -r devuelve siempre “ahora”, el sistema cree que la comprobación se acaba de hacer y deja de buscar e instalar actualizaciones automáticas.

Lo curioso es que para el usuario de a pie todo parecía ir bien: podías actualizar a mano sin problema con sudo apt update && sudo apt upgrade, pero el sistema de actualizaciones silenciosas quedaba roto sin que saltaran alarmas evidentes. Un ejemplo perfecto de cómo un bug de lógica en una utilidad básica puede tener consecuencias en cadena.

Este fallo se detectó rápido porque también afectaba a las propias pruebas del sistema. Canonical lanzó una actualización del paquete rust-coreutils (por ejemplo, a una versión tipo 0.2.2-0ubuntu2.1 o posterior) que corrigió el comportamiento de date -r y restableció el funcionamiento normal de las actualizaciones desatendidas.

sudo-rs: vulnerabilidades de seguridad en la elevación de privilegios

El segundo frente de problemas vino con sudo-rs, la reimplementación de sudo en Rust. Sudo es, probablemente, el comando más sensible del sistema, ya que permite ejecutar acciones como root de forma controlada y segura.

En ciertas configuraciones concretas de sudo-rs se detectaron dos vulnerabilidades importantes, que pasaron por un proceso formal de Divulgación Coordinada de Vulnerabilidades (CVD) antes de hacerse públicas:

• Exposición parcial de la contraseña al expirar el timeout: cuando lanzas un comando con sudo, tienes un tiempo limitado para escribir la contraseña. Si empiezas a teclear pero no pulsas Enter antes de que caduque el tiempo, sudo debería cerrar la entrada de forma silenciosa. Con el bug encontrado, en determinadas configuraciones, si el timeout se agotaba mientras estabas escribiendo, la parte de la contraseña que habías escrito podía mostrarse en la consola. Imagina ejecutar sudo apt update, empezar a escribir “micontra” y distraerte; al caducar el tiempo, tu contraseña, o parte de ella, aparecía en claro en el terminal.
• Reutilización indebida de credenciales: la segunda vulnerabilidad permitía que un atacante local, en determinadas condiciones de configuración, pudiera evitar autenticarse de nuevo aprovechando credenciales de sudo ya válidas más tiempo del previsto.

Estos fallos se corrigieron en versiones posteriores de sudo-rs (por ejemplo, 0.2.8-1ubuntu5.2 o similares) y Canonical publicó un Aviso de Seguridad de Ubuntu (USN) para desplegar los parches de forma rápida a todos los usuarios afectados.

Aquí la lección clave es que Rust no es una varita mágica: ofrece mucha seguridad frente a errores de memoria, pero no evita errores de lógica, validación o diseño. Reescribir herramientas críticas implica, inevitablemente, una fase de tropiezos que es mejor que suceda en versiones intermedias, no en una LTS.

Por qué estos fallos refuerzan el valor de las versiones intermedias

Puede sonar contraintuitivo, pero ver este tipo de bugs en una versión como Ubuntu 25.10 no es tanto un desastre como la demostración de que el modelo de pruebas funciona. Hay varios puntos positivos que conviene destacar.

Por un lado, las versiones intermedias son un campo de pruebas controlado. Canonical puede introducir cambios profundos (como la adopción de uutils y sudo-rs) sabiendo que el impacto se limitará a un ciclo de vida de 9 meses y a usuarios con mayor tolerancia al riesgo. Si algo sale mal, se corrige rápido y se llega a la siguiente LTS con la tecnología ya madura.

Por otro, la comunidad de software libre demuestra una vez más su capacidad de reacción y transparencia. El bug de date -r lo reportó un usuario; el equipo de Ubuntu y los desarrolladores de uutils lo priorizaron y resolvieron en cuestión de horas. Las vulnerabilidades de sudo-rs siguieron el proceso formal de CVD, se corrigieron en el proyecto original y llegaron a Ubuntu con un aviso de seguridad público.

Además, estos incidentes obligaron a añadir nuevas pruebas de regresión en uutils, en algunos casos incluso más exhaustivas que las que tenía GNU coreutils. Es decir, el ecosistema entero sale ganando: no solo se arregla el bug puntual, sino que se refuerzan las garantías de cara al futuro.

Que haya problemas en el camino es normal. Lo importante es que se detecten donde toca (en versiones intermedias), se resuelvan pronto y sirvan para llegar a la próxima LTS con un sistema más robusto, moderno y, a la larga, más seguro.

Errores clásicos al actualizar paquetes en Ubuntu (y cómo evitarlos)

Más allá del caso concreto de Rust, la mayoría de usuarios se topa con errores de actualización mucho más “mundanos”: dependencias rotas, bases de datos de paquetes corruptas, bloqueos de APT, falta de espacio, problemas de repositorios… Todo esto afecta tanto a LTS como a versiones intermedias.

Conviene repasar las causas más habituales y sus soluciones, porque muchas veces un sistema “roto” tras actualizar no es por culpa de Canonical, sino por una mezcla de repositorios raros, PPAs antiguos, poco espacio en disco y prisas.

Causas más frecuentes de fallos al actualizar Ubuntu

Cuando un sudo apt update o un sudo apt upgrade empiezan a escupir errores, casi siempre hay uno o varios responsables de esta lista:

• Listas de paquetes corruptas o desfasadas: la información en /var/lib/apt/lists se ha corrompido o está totalmente fuera de fecha.
• Dependencias no satisfechas: paquetes que requieren otros que faltan o no encajan con la versión actual.
• Gestor de paquetes bloqueado: otro proceso está usando APT o dpkg (por ejemplo, el Centro de software).
• Espacio insuficiente en la partición raíz (/): no hay sitio para descargar o desempaquetar las actualizaciones.
• Repositorios o PPAs rotos: servidores caídos, PPA desaparecidos, errores de firma GPG o URLs 404.

Se arreglan con unos pocos comandos bien usados. La mala, que si empiezas a borrar o toquetear cosas a lo loco, puedes empeorarlo todo. Así que mejor ir por partes.

Actualizar listas y paquetes: el primer paso obligatorio

Antes de volverse loco, siempre conviene hacer la pareja básica de comandos para poner al día la información de paquetes y aplicar las actualizaciones pendientes de forma normal:

sudo apt-get update
sudo apt-get upgrade

Con esto, APT descarga de nuevo las listas de paquetes y actualiza todos los instalados que puedan subirse de versión sin eliminar nada importante. Si todo va bien, puedes rematar con:

sudo apt-get dist-upgrade

Este último comando es más agresivo: resuelve nuevas dependencias y puede eliminar paquetes obsoletos cuando sea necesario, lo que a menudo desbloquea updates que se resisten.

Dependencias rotas: cuando “no se pueden instalar todas las actualizaciones”

Un mensaje clásico al intentar actualizar desde la interfaz gráfica o desde el terminal es que “no se pueden instalar todas las actualizaciones”, ofreciendo una “actualización parcial” que casi nunca es buena idea aceptar sin más.

En la mayoría de casos el problema son dependencias rotas o no satisfechas. Para forzar a APT a reparar la situación se utiliza:

sudo apt-get install -f

Este comando le dice al sistema que intente arreglar el lío de dependencias, instalando lo que falta o retirando lo que bloquea. Una vez ejecutado, suele ser buena idea volver a lanzar:

sudo apt-get upgrade

y comprobar si ya se puede actualizar todo sin que salte el aviso de actualización parcial.

Limpiar paquetes viejos y cachés que estorban

Con el paso del tiempo, el sistema acumula dependencias que ya no usa y archivos .deb descargados que solo ocupan espacio. Esto no solo ralentiza, también puede contribuir a algunos problemas de actualización.

Para hacer limpieza básica se utilizan:

sudo apt-get autoremove
sudo apt-get clean

El primero elimina paquetes de los que ya no depende nada, y el segundo borra los paquetes .deb almacenados en caché. Después de esto, es recomendable volver a actualizar. En versiones intermedias, donde se instalan y desinstalan cosas con más alegría, pasar estos comandos de vez en cuando es casi obligatorio.

Base de datos de paquetes y bloqueos de APT

Otro clásico son los errores relacionados con dpkg o con archivos de bloqueo que impiden que APT haga su trabajo. Suele ocurrir si se ha interrumpido una instalación, si hay un proceso colgado o si se ha cerrado a las bravas el Centro de software.

Si ves mensajes del tipo “no se pudo obtener el bloqueo /var/cache/apt/archives/lock” o “dpkg está ocupado”, puedes probar primero con:

sudo killall apt apt-get

Esto intenta cerrar cualquier proceso de APT que quede vivo. Si aun así el error persiste, se pueden eliminar a mano los archivos de bloqueo (con cuidado):

sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo rm /var/cache/apt/archives/lock

Después, conviene reconfigurar cualquier paquete que se haya quedado a medias con:

sudo dpkg --configure -a

y actualizar listas y paquetes de nuevo con sudo apt-get update y sudo apt-get upgrade. No borres cosas de /var/lib/dpkg a lo loco, o sí que puedes dejar el sistema KO.

Errores de repositorios: BADSIG, Hash Sum, 404 y compañía

Las versiones intermedias tienden a atraer PPAs, repos de terceros y experimentos varios. Eso multiplica la probabilidad de toparse con errores como BADSIG, Hash Sum mismatch, errores GPG y 404 al actualizar.

Algunos de los casos más típicos y cómo resolverlos son:

• Error BADSIG o problemas con firmas GPG: indica que la firma de un repositorio es inválida o se ha corrompido la información. Una forma de forzar la regeneración de listas es:

  cd /var/lib/apt && 
  sudo mv lists oldlist && 
  sudo mkdir -p lists/partial && 
  sudo apt-get clean && 
  sudo apt-get update
  

• GPG error: The following signatures couldn’t be verified: suele ocurrir con PPAs que no han instalado correctamente su clave pública. La solución pasa por añadir la clave GPG correcta al sistema usando el identificador que aparezca en el mensaje de error.
• Error Hash Sum o Hash Sum mismatch: la suma de verificación de los paquetes o listas no coincide, ya sea por corrupción local o desajuste con el servidor. Se arregla normalmente con:

  sudo rm -rf /var/lib/apt/lists/*
  sudo apt update
  

• Error 404 o “Failed to fetch”: el repositorio o PPA ya no existe, se ha movido o está caído. En estos casos hay que eliminar el repositorio problemático desde “Software y actualizaciones” o editando /etc/apt/sources.list y los archivos en /etc/apt/sources.list.d/, y preferir siempre el “Servidor principal”.

En general, cuantos más repositorios ajenos a Ubuntu añadas, más papeletas tienes para que una actualización de versión intermedia se complique. Mantener la lista de fuentes depurada es casi tan importante como actualizar el sistema en sí.

Falta de espacio en disco: el enemigo silencioso

Otro motivo muy infravalorado de errores al actualizar, sobre todo en portátiles con SSD ajustados, es simplemente no tener espacio libre suficiente en la partición raíz. El sistema necesita sitio para descargar, desempaquetar y configurar los nuevos paquetes.

Para revisar el uso de disco se utiliza:

df -h

Si ves que / está casi al 100%, toca liberar espacio: eliminar archivos personales pesados, limpiar paquetes antiguos con sudo apt-get autoremove y sudo apt-get clean, borrar kernels viejos si se han quedado acumulados, etc. Intentar una actualización mayor sin espacio libre es una receta para el desastre.

Actualizar de versión con do-release-upgrade (y no a lo loco)

Cuando toca saltar de una versión a otra (por ejemplo, de una intermedia a la siguiente, o de una LTS antigua a otra más nueva), lo recomendable es usar siempre la herramienta oficial en lugar de cambiar repositorios a mano.

El procedimiento básico desde terminal sería:

sudo apt update && sudo apt upgrade && sudo apt dist-upgrade
sudo do-release-upgrade

El comando do-release-upgrade comprueba compatibilidades, gestiona las fuentes de software, pregunta qué hacer con archivos de configuración modificados y, en general, minimiza la probabilidad de dejar el sistema en un limbo. Eso sí, hay que estar atento durante el proceso, porque suele hacer preguntas importantes (sobrescribir configs, reiniciar servicios, etc.).

Técnicamente es posible “bajar” de versión modificando /etc/apt/sources.list, cambiando nombres de repos (por ejemplo, de cosmic a bionic) y forzando un apt dist-upgrade en sentido contrario, pero es una maniobra delicada, llena de advertencias y con muchas posibilidades de que el sistema quede inestable. Si necesitas realmente volver a una versión anterior, lo más sano es reinstalar desde cero con su ISO y restaurar tus copias de seguridad.

LivePatch, Ubuntu Pro y el papel de las LTS en la estabilidad

Para muchos usuarios, el principal miedo a actualizar el sistema es tener que reiniciar en un momento incómodo. En entornos de servidor, esto es un problema serio. Ahí entra en juego Ubuntu Livepatch, disponible en las versiones LTS.

Livepatch permite aplicar parches de kernel “en caliente”, cargando el código nuevo en memoria y redirigiendo las llamadas a las funciones corregidas sin necesidad de reiniciar. La función forma parte de la oferta de Ubuntu Advantage / Ubuntu Pro, un servicio de Canonical que amplía el soporte hasta 10 años, añade parches de seguridad para decenas de miles de paquetes y ofrece soporte profesional.

Para un usuario doméstico, lo más interesante de esto es entender que las LTS están muy orientadas a ofrecer un nivel de estabilidad y soporte empresarial. Puedes activar Livepatch con:

sudo snap install canonical-livepatch
sudo canonical-livepatch enable [TOKEN]

utilizando un token gratuito (hasta 3 equipos) ligado a tu cuenta de Canonical. Si algún día decides que no lo quieres, puedes desactivarlo desde la pestaña “Livepatch” en la herramienta de controladores adicionales o desde la línea de comandos.

Esta separación clara entre el mundo LTS (con Livepatch, Pro, ciclos largos) y el mundo de las versiones intermedias (con cambios agresivos y 9 meses de soporte) refuerza la idea de que para jugar fuerte con novedades, lo lógico es hacerlo en las versiones intermedias, dejando las LTS para cuando necesitas tranquilidad absoluta.

Mantener Ubuntu al día: terminal, centro de software y actualizaciones sin Internet

Para mantener tu Ubuntu, sea intermedio o LTS, en buena forma, lo ideal es combinar actualizaciones regulares con buenas prácticas de copia de seguridad y algo de orden en los repositorios.

Desde terminal, el flujo típico de mantenimiento sería:

sudo apt update
sudo apt upgrade

para subir los paquetes a sus últimas versiones, seguido de un:

sudo reboot

cuando la actualización incluya kernel o componentes críticos. Si prefieres no tocar la consola, puedes usar la herramienta “Actualización de software” (el equivalente a un “Windows Update” en Ubuntu) que comprueba, descarga e instala parches de seguridad, actualizaciones del sistema y de programas instalados.

Incluso sin conexión a Internet se puede actualizar utilizando herramientas como apt-offline o apt-mirror, generando una solicitud de paquetes en el equipo sin red, descargando esos paquetes desde otro Ubuntu y aplicándolos después mediante:

sudo apt-offline install actualizaciones.zip

Es un proceso más engorroso, pero demuestra que el sistema de paquetes de Ubuntu es lo bastante flexible como para adaptarse a entornos muy variados.

Kernel y drivers: cuándo actualizar y cuándo no tocar

Otro foco de problemas al actualizar, especialmente en PCs de juegos con gráficas AMD o NVIDIA, es el kernel y los drivers propietarios. En Linux, la mayoría de controladores vienen integrados en el propio kernel y se actualizan junto a él, sin que tengamos que hacer nada.

Sin embargo, si instalas drivers propietarios (por ejemplo, controladores NVIDIA privativos) o módulos especiales para Wi-Fi u otros dispositivos, es posible que una actualización de kernel en una versión intermedia te deje con cuelgues, problemas de suspensión o pantallas negras si el driver no está adaptado todavía.

Para quienes necesitan ir siempre con el kernel más nuevo (por rendimiento, compatibilidad de hardware o simple curiosidad), existen herramientas como:

• Mainline: un fork gratuito de Ukuu que permite instalar y gestionar kernels mainline desde un interfaz gráfico.

  sudo add-apt-repository ppa:cappelikan/ppa && 
  sudo apt update && 
  sudo apt install mainline
  

• Ukuu: versión de pago (unos 16€) con interfaz más pulida y funciones avanzadas para manejar kernels en distintas distros basadas en Ubuntu.
• UKTools: herramienta gratuita en consola para descargar e instalar kernels desde el repositorio principal, vía GitHub.

  sudo apt install git make wget
  
  git clone https://github.com/usbkey9/uktools && cd uktools
  make
  

Eso sí, jugar con kernels en una versión intermedia ya de por sí experimental es sumar más variables a la ecuación. Lo sensato es no ir cambiando de kernel a ciegas salvo que tengas un motivo claro (por ejemplo, solucionar un bug concreto de hardware) y siempre manteniendo un kernel anterior instalado por si necesitas arrancar con él desde GRUB.

En cuanto a drivers, si no tienes necesidades muy especiales, lo mejor en Ubuntu es apoyarse en el panel de “Más controladores”, que permite alternar entre drivers libres y propietarios aprobados por Canonical. Actualizar manualmente desde webs de fabricantes solo tiene sentido cuando el soporte oficial se queda realmente corto.

Qué revisar después de una actualización grande

Tras una actualización de versión (especialmente si vienes de una intermedia a otra o de una LTS a la siguiente), lo habitual es que todo parezca igual, pero nunca está de más dedicar unos minutos a comprobar que todo sigue en su sitio:

• Verificar que tus archivos personales y documentos están donde deben.
• Comprobar que los programas clave siguen instalados y funcionando.
• Pasar de nuevo un sudo apt update && sudo apt upgrade por si han salido parches después de generar la imagen de la nueva versión.
• Probar funciones sensibles como suspensión, reanudación, sonido, red Wi-Fi y drivers de la GPU.
• Cómo comprobar qué versión de Ubuntu tienes y si aún está soportada

Si algo falla, la copia de seguridad es tu red de seguridad: puedes intentar arreglarlo (por ejemplo, reinstalando un paquete o cambiando de driver) sabiendo que, en el peor caso, siempre puedes reinstalar desde cero y restaurar tus datos.

Al final, usar una versión intermedia de Ubuntu como sistema del día a día es perfectamente viable si aceptas que actúa como banco de pruebas: vas a disfrutar antes que nadie de nuevos kernels, GNOME reciente, tecnologías como la “oxidación” del sistema con Rust o mejoras de rendimiento, pero a cambio asumes una probabilidad mayor de encontrarte con bugs como el de date -r o incidentes con utilidades críticas como sudo-rs. Mientras mantengas buenas copias de seguridad, controles los repositorios que añades, vigiles el espacio en disco y uses las herramientas oficiales de actualización (APT y do-release-upgrade), los errores típicos al actualizar no pasarán de ser pequeñas molestias que se solucionan con unos cuantos comandos y algo de calma, sin necesidad de reinstalar el sistema en cada salto de versión.