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 actualización 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 de una versión LTS a otra en la primera versión de actualización, porque esta incorpora las correcciones de los errores de instalación y actualización encontrados durante los primeros meses. Si la numeración no le resulta familiar, 26.04.1 no es una versión de Ubuntu distinta, sino la misma 26.04 con cuatro meses de correcciones integradas en los medios de instalación, y por eso es la primera versión que Canonical ofrecerá a un servidor existente.

Ejecute la comprobación en un equipo 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 se trata de 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 de soporte a largo plazo, y únicamente cuando existe su versión de actualización .1. Si establece Prompt=normal, recorrerá 24.10, 25.04 y 25.10 en ese orden; todas son 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 llega el día y no ocurre nada.

Todos los comandos siguientes debe ejecutarlos usted mismo, en su propio servidor y en el orden indicado. No se puede ensayar una actualización de versión en la máquina que se está actualizando. La actualización reemplaza el kernel y la biblioteca C, y necesita un reinicio para finalizar.

¿Debe actualizar en algún caso?

Ubuntu 24.04 recibe actualizaciones de seguridad estándar hasta 2029, por lo que un servidor de producción que funciona no está sujeto a ningún plazo. 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 ha aumentado» no es un motivo para tocar 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 mediante ella. Esa consola es la única forma de recuperar el acceso al servidor si SSH deja de funcionar, y descubrir que no funciona cuando ya está bloqueado es demasiado tarde.
• No puede permitirse una hora de inactividad y no tiene un plan 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 el DNS cuando el nuevo servidor responda correctamente. Mantendrá el servidor antiguo activo hasta comprobar que el nuevo funciona, y la reversión consistirá en cambiar el DNS en lugar de restaurar una copia. Si elige esta opción, empiece por los primeros diez minutos en un VPS nuevo y configure correctamente el nuevo servidor.

Paso 1: cree una copia de seguridad que pueda restaurar

Use dos capas porque fallan de formas distintas. Una instantánea del proveedor cubre todo el disco y permite restaurarlo en minutos, pero se crea mientras las bases de datos escriben. Por tanto, es coherente frente a fallos, no coherente con la aplicación. Una copia de seguridad a nivel de archivo con restic, almacenada fuera del servidor permite recuperar archivos individuales y proporciona una copia que sigue disponible si bloquean 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 crea un volcado coherente para tablas InnoDB. Las tablas MyISAM requieren detener la base de datos. El archivo tar /etc es el que realmente utilizará, 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 dañado, y una instalación de 24.04 actualizada sólo a medias 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 a medias. Que apt-mark showhold no muestre nada significa que ningún paquete está fijado a una versión que bloquee 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 en disco. El actualizador descarga todo el conjunto de paquetes nuevo antes de instalar nada y se detiene con un mensaje que identifica el sistema de archivos si no hay espacio suficiente.

df -h / /boot

El problema suele aparecer cuando quedan menos de 5 GB libres en /. Un /boot con menos de 300 MB libres 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.

Hay otra cosa que debe detener antes de empezar: si las actualizaciones de seguridad automáticas se ejecutan durante el proceso, mantienen bloqueado dpkg y el actualizador de la versión se detiene con Could not get lock /var/lib/dpkg/lock-frontend. Ejecute primero sudo systemctl stop unattended-upgrades y vuelva a iniciarlo cuando termine.

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

do-release-upgrade deshabilita 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á manteniendo 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 línea .list y los archivos deb822 .sources con los campos Types: y Suites:. La actualización deshabilita ambos. ubuntu-security-status --thirdparty muestra los paquetes instalados que no proporciona ningún archivo de Ubuntu. Es el recuento real de todo lo que ha añadido manualmente. Todo lo que aparece en /etc/apt/preferences.d/ es una fijación, y una fijación 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 comenzar. 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 posterior a la actualización:

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

Mantenga esa fuente deshabilitada hasta que el proveedor publique la versión correspondiente. Cambiar el nombre en clave por otro para el que el proveedor sí haya creado paquetes puede instalar 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 se detiene durante el desempaquetado. Esto deja dpkg configurado a medias y puede dejar el servidor sin una pila de red operativa para volver a conectarse. Ejecútelo dentro de un multiplexor de terminal. Así, el proceso sigue 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 abrirlo sin solicitarlo sería un cambio inesperado. Abra el puerto 1022 manualmente antes de iniciar la actualización y ciérrelo cuando termine con sudo ufw delete allow 1022/tcp. Tenga en cuenta que su proveedor puede ejecutar un segundo firewall desde el 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 continuó mientras estuvo desconectado. Si no fue así y encuentra un estado de dpkg parcialmente configurado o fuentes de apt que están en parte en noble y en parte en resolute, la recuperación de una actualización de versión fallida explica cómo reparar el estado de los paquetes y saber cuándo dejar de reparar y restaurar la instantánea en su lugar.

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 hayan modificado. Por tanto, cada pregunta corresponde a un archivo que editó de forma intencionada. Pulsar Intro para 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 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 este equipo.

Conservar su archivo tiene un coste: no obtiene los nuevos valores predeterminados. Haga la reconciliación después, cuando el equipo ya esté operativo y no tenga la presión del tiempo.

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

Cada archivo que aparece en la lista es la versión del mantenedor, guardada junto a la suya. Compare los archivos uno por uno y copie la configuración relevante. Hay dos 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 un archivo de biblioteca compartida eliminado del disco puede bloquearse ante una petición posterior, cuando usted 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. Si muestra alguna, esa será su siguiente tarea. El apt update final obtiene 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 eso, 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 todo parece funcionar con normalidad. Por este motivo, muchas personas descubren el problema varios meses después.

pg_lsclusters

Si aparecen dos clústeres en la lista, todavía no 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 vacío de 18, porque pg_upgradecluster no escribe en un clúster de destino que ya existe. El método predeterminado vuelca 16 y lo carga 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 bases de datos grandes. Cuando termine, lea la columna Port: el clúster nuevo asume el puerto 5432 y el antiguo queda detenido. Ejecute usted mismo el 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. Solo 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 hay que configurarla. El servicio falla y journalctl -u mysql -n 50 muestra directamente la variable desconocida. Elimine esa línea del archivo ubicado 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 use no puede iniciar sesión. Compruébelo mientras siga usando 8.0:

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

Cambie 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 usar caching_sha2_password, puede volver a habilitar el plugin antiguo en 8.4 añadiendo mysql_native_password=ON en [mysqld]. Úselo como solución temporal con una fecha de retirada, porque el plugin desaparecerá por completo.

PHP 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, pruebe la configuración y recargue nginx:

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

Con Apache y mod_php el síntoma es diferente: 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 configuró el servidor 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.

Los ajustes de php.ini tampoco se transfieren. memory_limit, upload_max_filesize y cualquier otro valor que haya definido 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 todo el archivo antiguo sobre el nuevo arrastra los valores predeterminados de 8.3 a 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ó ese origen y la extensión simplemente no está instalada.

Los certificados requieren una comprobación específica. Ejecute sudo certbot renew --dry-run después de la actualización. Esto prueba toda la ruta de renovación, incluido el hook de recarga del servidor web, sin modificar el certificado activo. Si un hook llama a un nombre de servicio o a un binario que ha cambiado, 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 hooks.

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

El indicador sshd_config es donde muchos se quedan sin acceso. Responder Y instala el archivo del mantenedor y 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 incluida escucha en el puerto 22, la siguiente conexión se rechaza y la sesión actual es la última que tiene.

Evítelo antes de actualizar. /etc/ssh/sshd_config en 24.04 empieza con Include /etc/ssh/sshd_config.d/*.conf, y OpenSSH conserva el primer valor que lee para cada ajuste. Por eso, un archivo adicional incluido al principio tiene prioridad sobre todo lo que aparece después. Mueva 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 quede nada suyo en /etc/ssh/sshd_config, ese aviso deja de ser importante: 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é configurado donde cree:

systemctl is-enabled ssh.socket

Si muestra enabled, systemd controla el puerto de escucha y la línea Port de sshd_config se ignora. Ubuntu usa activación por sockets para sshd desde 22.10, y por eso modificar Port 2222 puede parecer que no tiene efecto. Configure el puerto en la unidad de socket con sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

El ListenStream= vacío es obligatorio. Borra el valor heredado. Sin él, el socket también escucha en 22 además de 2222. Aplíquelo con sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Después de actualizar, 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. Endurecimiento de SSH en un VPS repasa los ajustes que conviene conservar en ese archivo adicional.

Si ya es demasiado tarde, la consola web de su proveedor permite iniciar sesión sin usar SSH. Inicie sesión allí, corrija la configuración, ejecute sudo sshd -t y reinicie el servicio. Precisamente para eso sirve probar el acceso a la consola antes de actualizar, no durante la actualización.

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 ese valor ofrece la siguiente versión de soporte a largo plazo sólo después de que exista su primera actualización de versión. 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 ese valor sin cambios en lugar de cambiarlo a Prompt=normal, que lo llevaría por las versiones intermedias.

¿Tengo que reiniciar el servidor para terminar 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 usando los anteriores hasta que se reinicia. do-release-upgrade solicita reiniciar al final. Una máquina que se deja en ejecución hasta «más tarde» sigue funcionando con una mezcla 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 hayan iniciado.

¿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, no en 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 disponga de una instantánea y de acceso de consola comprobado. El procedimiento de actualización en el mismo servidor está bien establecido, pero durante la hora que dura no permite una reversión sencilla.

¿Qué ocurre si se pierde 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. Esto deja dpkg configurado 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 la operación. El actualizador también inicia un daemon SSH adicional en el puerto 1022 como segunda vía de acceso. Sin embargo, no abre el firewall para ese puerto. Permita primero el puerto 1022 y ciérrelo después.

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

La ruta del socket de PHP FPM cambió con la versión. Ubuntu 24.04 usa PHP 8.3 y 26.04 usa PHP 8.5. Por eso, /run/php/php8.3-fpm.sock ya no existe, mientras que el vhost de nginx todavía la especifica. 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.