Actualizar Ubuntu 24.04 a 26.04 en un VPS

¿Cuándo se puede actualizar Ubuntu 24.04 a 26.04?

Puede actualizar Ubuntu 24.04 a 26.04 en un VPS cuando se publique la versión de mantenimiento 26.04.1, prevista para el 27 de agosto de 2026. Hasta entonces, un servidor 24.04 no verá la nueva versión, de forma intencionada. Ubuntu 26.04 LTS (Resolute Raccoon) se publicó el 23 de abril de 2026, pero Canonical sólo habilita la ruta de actualización entre versiones LTS en la primera versión de mantenimiento, porque esta incorpora las correcciones de los errores de instalación y actualización encontrados durante los primeros meses.

Ejecute la comprobación en un equipo con 24.04 a principios de agosto de 2026 y verá esto:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

No es un fallo del servidor. /etc/update-manager/release-upgrades contiene Prompt=lts en Ubuntu Server, lo que significa que la herramienta sólo ofrece la siguiente versión con soporte a largo plazo, y únicamente cuando existe su versión de mantenimiento .1. Si establece Prompt=normal, el proceso le guiará por 24.10, 25.04 y 25.10 sucesivamente, versiones intermedias que ya han llegado al final de su vida útil. Déjelo en lts y espere. Las fechas del calendario de Canonical pueden cambiar, así que vuelva a comprobarlo si pasa el día sin novedades.

Cada comando siguiente debe ejecutarlo usted en su propio servidor, en el orden indicado. Una actualización de versión no se puede ensayar en la máquina que está actualizando. Sustituye el kernel y la biblioteca C, y necesita un reinicio para finalizar.

¿Debe actualizar realmente?

Ubuntu 24.04 recibe actualizaciones de seguridad estándar hasta 2029, por lo que un servidor de producción operativo no tiene una fecha límite. Actualice porque necesita algo que incluya 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 o el kernel 7.0. «El número aumentó» no es una razón para modificar una máquina que presta servicio a clientes.

No actualice en el mismo sistema cuando se cumpla alguna de estas condiciones:

• Nunca ha abierto la consola de su proveedor (VNC o serie) ni ha iniciado sesión desde ella. Esa consola es la única forma de recuperar el acceso al equipo si SSH deja de funcionar. Descubrir que no funciona cuando ya no tiene acceso es demasiado tarde.
• No puede permitirse una hora de interrupción y no tiene un procedimiento de reversión.
• Su stack depende de un repositorio de terceros que todavía no ha publicado paquetes para resolute.
• El servidor se configuró manualmente hace más de dos años y nadie sabe qué contiene.

A menudo es mejor usar la alternativa: cree un VPS nuevo con 26.04, instale su stack y restaure los datos. Después, cambie DNS cuando responda correctamente. Mantenga el servidor antiguo en funcionamiento hasta que el nuevo haya demostrado ser fiable. Así, la reversión consiste en cambiar DNS en lugar de restaurar una copia. Si elige este método, empiece por los primeros diez minutos en un VPS nuevo y configure correctamente el equipo nuevo.

Paso 1: haga una copia de seguridad que pueda restaurar

Use dos capas porque fallan de distintas formas. Una instantánea del proveedor cubre todo el disco y permite restaurarlo en minutos, pero se toma mientras las bases de datos escriben. Por tanto, es coherente ante fallos, pero no coherente con la aplicación. Una copia de seguridad a nivel de archivos con restic, almacenada fuera del servidor permite recuperar archivos individuales y proporciona una copia que sobrevive al bloqueo de su cuenta.

Vuelque primero las bases de datos manualmente. Un volcado es la única copia de seguridad de una base de datos en la que puede confiar sin detenerla.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction sólo genera un volcado coherente para tablas InnoDB. Las tablas MyISAM requieren detener la base de datos. El archivo tar /etc es el que realmente necesitará, porque contiene todos los archivos de configuración sobre los que la actualización está a punto de hacerle preguntas.

Una copia de seguridad que nunca ha restaurado es sólo una suposición. Extraiga ahora un archivo de ella, antes de necesitarlo bajo presión.

Paso 2: aplique primero todos los parches de 24.04

do-release-upgrade no se ejecuta en un sistema con un estado de paquetes incorrecto, y una 24.04 con parches aplicados sólo parcialmente dificulta interpretar cualquier fallo posterior.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

Que dpkg --audit no muestre nada significa que ningún paquete está configurado parcialmente. Que apt-mark showhold no muestre nada significa que ningún paquete está fijado a una versión que bloquearía la actualización. Libere cada paquete que aparezca con sudo apt-mark unhold y el nombre del paquete, o acepte que la retención existe por un motivo y deténgase aquí.

Reinicie si cambió el kernel. Así la actualización se ejecuta desde una máquina que usa el código que cree estar usando.

[ -f /var/run/reboot-required ] && sudo reboot

Después, compruebe el espacio disponible en disco. El actualizador descarga todo el conjunto nuevo de paquetes antes de instalar nada. Si no hay espacio suficiente, se detiene y muestra un mensaje con el sistema de archivos afectado.

df -h / /boot

Si quedan menos de unos 5 GB libres en /, es probable que este proceso falle. Un /boot con menos de 300 MB disponibles falla más adelante, durante la instalación del kernel, con No space left on device. La causa habitual son los kernels antiguos, y sudo apt --purge autoremove los elimina.

Antes de empezar, detenga también otro proceso: si las actualizaciones de seguridad automáticas se ejecutan durante la actualización, mantienen bloqueado dpkg y el actualizador de versiones se detiene con Could not get lock /var/lib/dpkg/lock-frontend. Ejecute primero sudo systemctl stop unattended-upgrades y vuelva a iniciar el proceso cuando termine.

Paso 3: compruebe los repositorios de terceros y los paquetes fijados

do-release-upgrade desactiva todas las fuentes de APT que no pertenecen a Ubuntu, porque un paquete creado para noble puede romper un sistema resolute. Después vuelve a habilitar las que reconoce y deja comentadas las demás. Sepa qué está utilizando antes de que la herramienta decida por usted.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 usa dos formatos en ese directorio: los archivos antiguos de una sola línea .list y los archivos .sources de deb822, con los campos Types: y Suites:. La actualización desactiva ambos. ubuntu-security-status --thirdparty muestra los paquetes instalados que no proporciona ningún archivo de Ubuntu. Es el recuento exacto de lo que ha añadido manualmente. Cualquier elemento de /etc/apt/preferences.d/ es una prioridad fijada, y una prioridad escrita para noble seguirá seleccionando un paquete antiguo en la nueva versión.

Para cada repositorio de terceros, confirme que el proveedor haya publicado una versión para el nuevo nombre en clave antes de empezar. Las suites de Docker aparecen en https://download.docker.com/linux/ubuntu/dists/, y los demás proveedores exponen el mismo directorio. Una fuente que apunte a una suite inexistente muestra este mensaje en el primer apt update después de la actualización:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Mantenga esa fuente desactivada hasta que el proveedor publique la versión correspondiente. Editar el nombre en clave para usar uno para el que el proveedor sí haya creado paquetes hace que instale paquetes vinculados a bibliotecas de sistema incorrectas.

Paso 4: ejecute la actualización en tmux, no en una shell SSH normal

Si la conexión se interrumpe mientras do-release-upgrade se ejecuta en una shell de inicio de sesión normal, el proceso recibe SIGHUP y termina durante la descompresión. Esto deja dpkg configurado sólo parcialmente y puede dejar el servidor sin una pila de red operativa a la que volver a conectarse. Ejecútelo dentro de un multiplexor de terminal. Así, el proceso permanece activo en el servidor aunque el cliente se desconecte.

sudo apt install -y tmux
tmux new -s upgrade

Dentro de esa sesión:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

El actualizador inicia un segundo daemon SSH en el puerto 1022 antes de cambiar nada, y lo indica:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

No abre ese puerto en el firewall porque abrir un puerto sin solicitarlo sería un cambio inesperado. Abra el puerto 1022 manualmente antes de comenzar y ciérrelo cuando termine con sudo ufw delete allow 1022/tcp. Recuerde que el proveedor puede tener un segundo firewall en su panel de control, fuera del servidor.

Si la conexión se interrumpe de todos modos, vuelva a iniciar sesión y ejecute tmux attach -t upgrade. La actualización siguió ejecutándose mientras estuvo desconectado.

Paso 5: responda deliberadamente a las preguntas sobre los archivos de configuración

dpkg sólo pregunta por los archivos que usted o un script han modificado. Por tanto, cada pregunta corresponde a un archivo que editó deliberadamente. Pulsar Intro para hacer que desaparezca es la forma en que un servidor reforzado vuelve silenciosamente a la configuración predeterminada.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Pulse D primero, siempre. Lea los cambios y conserve después su versión con N. La opción predeterminada ya es N, que es la respuesta segura, porque su archivo funciona actualmente y el archivo del paquete nunca se ha ejecutado en esta máquina.

Conservar su archivo tiene un coste: no obtiene los valores predeterminados nuevos. Compare y armonice los archivos después, cuando el sistema vuelva a estar operativo y no esté bajo presión de tiempo.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Cada archivo que muestra esta opción es la versión del mantenedor, guardada junto a la suya. Compare los archivos uno por uno y transfiera la configuración importante. Hay dos casos que requieren especial cuidado: /etc/ssh/sshd_config, porque una respuesta incorrecta termina su sesión, y la configuración del servidor web, porque una respuesta incorrecta deja los sitios fuera de servicio.

La actualización también pregunta qué servicios se deben reiniciar mediante needrestart. Acepte la lista completa. Un daemon que siga ejecutándose con una biblioteca compartida que se haya eliminado del disco puede fallar en una solicitud posterior, cuando no esté supervisándolo.

Paso 6: reinicie y compruebe la máquina

sudo reboot

Cuando vuelva a estar disponible:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a debe mostrar Release: 26.04 y Codename: resolute. uname -r debe mostrar un kernel 7.0. systemctl --failed debe mostrar cero unidades; cualquier unidad que aparezca será su siguiente tarea. El apt update final descarga las actualizaciones publicadas desde que se crearon las imágenes de la versión.

PostgreSQL 16 a 18: el clúster que queda atrás sin que nadie lo advierta

Ubuntu 24.04 incluye PostgreSQL 16 y 26.04 incluye PostgreSQL 18. La actualización instala 18 junto a 16, pero no mueve los datos. La capa postgresql-common de Debian crea un clúster nuevo y vacío para la nueva versión principal en el siguiente puerto libre. Por tanto, 16 conserva el puerto 5432 con todos los datos y 18 queda vacío en 5433. La aplicación sigue conectándose a 5432 y no se aprecia ningún problema. Por eso muchas personas descubren la situación meses después.

pg_lsclusters

Si aparecen dos clústeres, significa que todavía no se ha hecho la migración. Hágala cuando pueda detener la aplicación:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Elimine primero el clúster 18 vacío, porque pg_upgradecluster no escribirá en un clúster de destino que ya exista. El método predeterminado vuelca 16 y carga los datos de nuevo en 18, por lo que necesita espacio libre en disco equivalente aproximadamente al tamaño de la base de datos. -m upgrade usa pg_upgrade en su lugar y es mucho más rápido con una base de datos grande. Cuando termine, lea la columna Port: el clúster nuevo asumirá el puerto 5432 y el antiguo quedará detenido. Ejecute manualmente el proceso de análisis, porque un clúster recién cargado no tiene estadísticas y las primeras consultas serán lentas.

Pruebe la aplicación con el clúster nuevo durante unos días. Sólo después elimine el antiguo:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

El directorio de datos del clúster antiguo es la forma más rápida de revertir el cambio. No lo elimine el día de la actualización.

MySQL 8.0 a 8.4: la opción eliminada que impide iniciar el servidor

26.04 actualiza MySQL de 8.0 a 8.4 LTS, y dos cambios afectan a los servidores.

Primero, mysqld no inicia si su configuración contiene una opción que la nueva versión ha eliminado. default_authentication_plugin es la más habitual, porque muchas guías antiguas indican que debe establecerse. El servicio falla y journalctl -u mysql -n 50 identifica directamente la variable desconocida. Elimine esa línea del archivo situado en /etc/mysql/mysql.conf.d/ y, después, sudo systemctl start mysql.

Segundo, el plugin mysql_native_password ya no está habilitado de forma predeterminada en 8.4, por lo que una cuenta que todavía lo utilice no podrá iniciar sesión. Compruébelo mientras todavía use 8.0:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Migre todas las cuentas que muestren mysql_native_password antes de la actualización y, después, actualice la contraseña en la configuración de la aplicación:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Si una biblioteca cliente es demasiado antigua para comunicarse mediante caching_sha2_password, puede volver a habilitar el plugin antiguo en 8.4 añadiendo mysql_native_password=ON en [mysqld]. Considérelo una solución temporal con una fecha de retirada, porque el plugin desaparecerá por completo.

PHP de 8.3 a 8.5: los vhosts apuntan a un socket que ya no existe

24.04 incluye PHP 8.3 y 26.04 incluye PHP 8.5. Los paquetes se instalan en rutas versionadas y nada reescribe la configuración del servidor web. Un vhost de nginx que contiene fastcgi_pass unix:/run/php/php8.3-fpm.sock; ahora apunta a un socket que ningún proceso crea, por lo que todas las peticiones PHP devuelven 502 y el registro de errores de nginx muestra:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Apunte al nuevo socket, compruebe la configuración y recargue el servicio:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

En Apache con mod_php el síntoma es distinto: Apache no se inicia y sudo apache2ctl -t informa de que no puede cargar libphp8.3.so porque el archivo no existe. El módulo habilitado es un enlace simbólico a un paquete que ya no está instalado.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Si preparó el sistema siguiendo una pila LAMP en Ubuntu 24.04, conviene comprobar ambas rutas, porque la guía deja un nombre de módulo versionado y un socket versionado.

La configuración de ajuste de php.ini tampoco se conserva. memory_limit, upload_max_filesize y cualquier otro valor que haya configurado se encuentran en /etc/php/8.3/, y el nuevo árbol parte de los valores predeterminados. Compare los dos archivos y copie los valores manualmente. Copiar el archivo antiguo completo sobre el nuevo introduce los valores predeterminados de 8.3 en una instalación de 8.5. Después ejecute php -m y compare: una extensión instalada como php8.3-redis necesita su paquete php8.5- y, si procedía de un PPA, el actualizador deshabilitó esa fuente y la extensión simplemente no está instalada.

Los certificados requieren una comprobación independiente. Ejecute sudo certbot renew --dry-run después de la actualización. Esto prueba toda la ruta de renovación, incluido el enlace de recarga del servidor web, sin modificar el certificado activo. Si un enlace invoca un nombre de servicio o un binario que cambió, el fallo aparece aquí, de forma visible, en lugar de producirse silenciosamente dentro de 60 días. Certbot con Let's Encrypt en nginx explica cómo deben ser esos enlaces.

SSH: el fallo que termina la sesión en la que está trabajando

El indicador sshd_config es donde los usuarios se quedan sin acceso. Responder Y instala el archivo del mantenedor, que descarta PermitRootLogin, PasswordAuthentication, AllowUsers, Port y cualquier otra línea que haya añadido. Si el firewall sólo permite un puerto personalizado y la configuración empaquetada escucha en 22, la siguiente conexión se rechaza y la sesión que tiene abierta es la última disponible.

Evítelo antes de actualizar. /etc/ssh/sshd_config en 24.04 comienza con Include /etc/ssh/sshd_config.d/*.conf, y OpenSSH conserva el primer valor que lee para cada ajuste. Por tanto, un archivo adicional incluido al principio tiene prioridad sobre todo lo que aparece después. Traslade sus ajustes a un archivo que dpkg no administre:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Cuando ya no haya nada suyo en /etc/ssh/sshd_config, ese indicador deja de ser relevante: cualquiera de las respuestas conserva sus ajustes porque están en otro archivo.

Un puerto personalizado requiere una comprobación adicional, porque quizá no esté definido donde cree:

systemctl is-enabled ssh.socket

Si muestra enabled, systemd administra el puerto de escucha y la línea Port de sshd_config se ignora. Ubuntu usa activación mediante sockets para sshd desde 22.10. Esta es la razón por la que editar Port 2222 parece no tener efecto. Defínalo en la unidad de socket con sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

El ListenStream= vacío es necesario. Borra el valor heredado. Sin él, el socket escucha tanto en 22 como en 2222. Aplíquelo con sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Después de la actualización, antes de cerrar la sesión actual:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

A continuación, abra un segundo terminal en su propio equipo y vuelva a iniciar sesión. Un shell operativo en ese segundo terminal es la única prueba válida. Mantenga abierta la primera sesión hasta conseguirlo. Endurecer SSH en un VPS explica los ajustes que conviene conservar en ese archivo adicional.

Si ya es demasiado tarde, la consola web de su proveedor le proporciona un acceso que no usa SSH. Inicie sesión allí, corrija la configuración, ejecute sudo sshd -t y reinicie el servicio. Precisamente por eso debe probar el acceso a la consola antes de una actualización, no durante ella.

FAQ

¿Por qué do-release-upgrade muestra "No new release found" en Ubuntu 24.04?

Porque /etc/update-manager/release-upgrades contiene Prompt=lts en Ubuntu Server, y esa configuración ofrece la siguiente versión de soporte a largo plazo sólo después de que exista su primera actualización de punto. Ubuntu 26.04 LTS se publicó el 23 de abril de 2026, y 26.04.1 está programado para el 27 de agosto de 2026. Hasta ese día, un servidor 24.04 no verá ninguna versión nueva. Mantenga la configuración sin cambios en lugar de cambiarla a Prompt=normal, que le haría pasar por las versiones intermedias.

¿Tengo que reiniciar el servidor para finalizar la actualización?

Sí. La actualización instala un kernel nuevo, una biblioteca C nueva y un sistema init nuevo. El sistema en ejecución sigue utilizando los anteriores hasta que se reinicia. do-release-upgrade solicita reiniciar al final, y una máquina que permanece en ejecución hasta «más tarde» está utilizando una combinación de dos versiones. Cuando vuelva a estar disponible, compruebe uname -r para confirmar el kernel nuevo y systemctl --failed para identificar los servicios que no se recuperaron.

¿Debo actualizar el servidor existente o crear uno nuevo con 26.04?

Cree uno nuevo cuando sea posible. Un VPS nuevo permite instalar la pila, restaurar los datos y probarlo todo mientras el servidor antiguo sigue atendiendo tráfico. Así, la reversión consiste en cambiar el DNS en lugar de restaurar una copia de seguridad. Actualice el servidor existente cuando contenga datos de estado difíciles de mover, cuando el proveedor facture por máquina o cuando tenga una instantánea y acceso de consola probado. La actualización del servidor existente es un procedimiento habitual, pero durante la hora que dura es irreversible.

¿Qué ocurre si se interrumpe mi conexión SSH durante la actualización?

En un shell de inicio de sesión normal, el proceso recibe SIGHUP y termina a mitad de la operación, lo que deja dpkg configurado sólo parcialmente. Inícielo dentro de tmux o screen para que el proceso sobreviva. Después, vuelva a conectarse y ejecute tmux attach -t upgrade para continuar. El actualizador también inicia un daemon SSH adicional en el puerto 1022 como segunda vía de acceso, pero no abre el firewall para ese puerto. Por tanto, permita primero el puerto 1022 y ciérrelo después.

Mi sitio PHP devuelve 502 después de la actualización. ¿Qué se rompió?

La ruta del socket de PHP FPM cambió con la versión. Ubuntu 24.04 ejecuta PHP 8.3 y 26.04 ejecuta PHP 8.5. Por eso, /run/php/php8.3-fpm.sock ya no existe mientras el vhost de nginx todavía hace referencia a ella. El registro de errores de nginx muestra connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Actualice fastcgi_pass para usar el socket de 8.5, ejecute sudo nginx -t y vuelva a cargar nginx. En Apache con mod_php, la corrección equivalente es sudo a2dismod php8.3, seguida de sudo a2enmod php8.5 y un reinicio.