Actualizar Ubuntu 24.04 a 26.04 en un VPS

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

Ahora puede actualizar Ubuntu 24.04 a 26.04 en un VPS. Desde el 29 de septiembre de 2026, cuando Canonical habilitó las actualizaciones desde 24.04 LTS, do-release-upgrade en un servidor 24.04 ofrece 26.04.1. 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 cuando está disponible la primera versión de mantenimiento, porque esa versión incorpora las correcciones de los errores de instalación y actualización detectados durante los primeros meses. Esta vez, la espera se prolongó más allá de la propia versión de mantenimiento: 26.04.1 se publicó el 27 de agosto de 2026, y Canonical retrasó la actualización unas semanas más para incluir backports planificados que corregían regresiones en una versión reciente de rust-coreutils. Si esta numeración es nueva para usted, 26.04.1 no es una versión distinta de Ubuntu, sino la misma 26.04 con cuatro meses de correcciones incorporadas en el medio de instalación, y por eso es la primera versión que Canonical ofrecerá a un servidor existente.

Hasta el 29 de septiembre, al ejecutar la comprobación en un servidor 24.04 se mostraba lo siguiente:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Eso no indicaba un fallo del servidor. Si todavía aparece hoy, compruebe la configuración de la que depende. /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 sólo cuando Canonical habilita la ruta correspondiente. Déjelo en lts de todos modos, porque en una versión posterior normal también ofrecería las versiones intermedias de corta duración. Durante la espera, Canonical ofreció do-release-upgrade -d a quienes no quisieran esperar. Ahora que la ruta está habilitada, el comando simple es el que Canonical indica en su anuncio para los servidores. Lea qué cambió en 26.04.1 y cuándo se habilitó la ruta de actualización antes de empezar. Un servidor que todavía use 22.04 no puede realizar directamente este salto, porque el actualizador sólo ofrece la siguiente versión LTS. Por eso, actualizar 22.04 a 26.04 pasando por 24.04 cubre el primer salto y la instantánea que debe crear antes del segundo.

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

¿Debe actualizar en absoluto?

Ubuntu 24.04 recibe actualizaciones de seguridad estándar hasta 2029, por lo que un servidor de producción operativo 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 una razón 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 a través de 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 mecanismo de reversión.
• Su pila 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 pila y restaure los datos. Después, cambie el DNS cuando el nuevo servidor responda correctamente. Mantendrá el servidor antiguo en funcionamiento hasta comprobar que el nuevo funciona de forma fiable, y la reversión consistirá en un cambio de DNS en lugar de una restauración. Si elige este método, empiece por los primeros diez minutos en un VPS nuevo y configure correctamente el nuevo servidor.

Paso 1: cree una copia de seguridad desde la 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 toma mientras las bases de datos están escribiendo, por lo que es consistente después de un bloqueo del sistema, no coherente con la aplicación. Una copia de seguridad a nivel de archivos con restic, almacenada fuera del servidor le proporciona archivos individuales y una copia que sobrevive al bloqueo de su cuenta.

Primero, vuelque las bases de datos manualmente. Un volcado es una forma de hacer una copia de seguridad de una base de datos en ejecución.

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 proporciona un volcado consistente para las tablas InnoDB. Las tablas MyISAM necesitan bloqueos para obtener un volcado consistente. 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 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 se niega a ejecutarse en un sistema con un estado de paquetes dañado, y una 24.04 actualizada sólo a medias hace que todos los fallos posteriores sean más difíciles de interpretar.

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

Si dpkg --audit no muestra nada, ningún paquete está configurado a medias. Si apt-mark showhold no muestra nada, ningún paquete tiene un bloqueo de dpkg. Esto no muestra las preferencias de APT fijadas, que son un mecanismo independiente y también pueden impedir la actualización de un paquete; el paso 3 las comprueba. Libere todo lo que muestre showhold con sudo apt-mark unhold y el nombre del paquete, o acepte que el bloqueo existe por un motivo y deténgase aquí.

Reinicie si cambió el kernel, para actualizar desde una máquina que ejecuta el código que cree estar ejecutando.

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

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

df -h / /boot

Los kernels antiguos suelen ser la causa, 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 sudo systemctl stop unattended-upgrades primero y vuelva a iniciarlo cuando haya terminado.

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

De forma predeterminada, do-release-upgrade comenta todas las fuentes de APT que no pertenecen a Ubuntu, porque un paquete compilado para noble puede romper un sistema resolute. Su opción --allow-third-party los mantiene habilitados, lo que implica exactamente ese riesgo. Sepa qué está aceptando 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 .sources en formato deb822, con los campos Types: y Suites:. Una actualización predeterminada deshabilita ambos. ubuntu-security-status --thirdparty muestra los paquetes instalados que no proporciona ningún archivo de Ubuntu. Es el recuento real de lo que ha añadido por su cuenta. Un archivo de /etc/apt/preferences.d/ se interpreta como una preferencia de versión sólo si su nombre no tiene extensión o termina en .pref y contiene únicamente letras, dígitos, guiones, guiones bajos y puntos. APT ignora cualquier otro archivo, normalmente con un aviso. Una preferencia que menciona noble puede mantener un paquete en una versión antigua después de la actualización, según las versiones que sigan disponibles y la prioridad que establezca la preferencia. Lea cada archivo y decida si todavía corresponde mantenerlo.

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 otros proveedores exponen el mismo directorio. Una fuente que apunte a una suite inexistente muestra esto 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.

Docker publica ahora una suite resolute. Mantenga deshabilitada cualquier fuente cuya suite no exista hasta que el proveedor la publique. Cambiar el nombre en clave por otro para el que el proveedor sí haya compilado paquetes es una forma de instalar paquetes enlazados con las bibliotecas del sistema incorrectas.

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

El actualizador del servidor normalmente se ejecuta dentro de GNU screen y permite volver a conectarse después de una desconexión, por lo que perder la conexión SSH no detiene por sí solo la actualización. Ejecútelo también dentro de su propia sesión de tmux para tener una sesión con nombre a la que pueda volver a conectarse.

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 acceso en el firewall sin solicitarlo sería una mala práctica. Abra el puerto 1022 usted mismo antes de iniciar la actualización y ciérrelo cuando termine con sudo ufw delete allow 1022/tcp. Recuerde que su proveedor puede ejecutar 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 continuó mientras estuvo desconectado. Si no fue así y vuelve a encontrar un dpkg parcialmente configurado o fuentes de apt que son en parte noble y en parte resolute, recuperar una actualización de versión fallida explica cómo reparar el estado de los paquetes y cuándo dejar de intentar repararlo y restaurar la snapshot en su lugar.

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

dpkg sólo solicita confirmación para los archivos que usted o un script hayan modificado. Por tanto, cada pregunta corresponde a un archivo modificado por usted o por un script, y pulsar Enter conserva la versión actual de forma 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 qué ha cambiado y después decida si conserva su versión con N o instala la versión del responsable del paquete. La opción predeterminada ya es N, pero conservar el archivo antiguo no es seguro para todos los paquetes: algunos cambios de configuración son necesarios para que el sistema actualizado funcione.

Conservar su archivo tiene un coste: no obtiene los valores predeterminados nuevos. Compare las versiones después, cuando el servidor esté operativo y no trabaje con presión de tiempo.

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

Cada archivo que aparece contiene la versión del responsable del paquete, guardada junto a la suya. Compare los archivos uno por uno y copie la configuración relevante. Hay dos que requieren especial atención: /etc/ssh/sshd_config, porque una respuesta incorrecta termina la sesión, y la configuración del servidor web, porque una respuesta incorrecta deja los sitios fuera de servicio.

Desde Ubuntu 24.04, needrestart reinicia automáticamente los servicios afectados de forma predeterminada. Si restableció su modo interactivo, acepte la lista completa. Un daemon que siga utilizando una biblioteca compartida antigua permanece expuesto a errores corregidos por la actualización hasta que se reinicia.

Paso 6: reinicie y compruebe el equipo

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 debería mostrar Release: 26.04 y Codename: resolute. uname -r debería mostrar un kernel 7.0. systemctl --failed debería mostrar cero unidades; cualquier unidad que aparezca será su siguiente tarea. El apt update final actualiza los índices de paquetes y apt full-upgrade instala las actualizaciones publicadas desde que la actualización obtuvo sus paquetes.

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 principal al instalar el paquete del servidor sólo cuando todavía no existe ningún clúster. Por tanto, un clúster existente de PostgreSQL 16 no adquiere automáticamente un clúster 18 vacío en el puerto 5433. La aplicación sigue conectándose al puerto 5432 y nada parece incorrecto. Por eso este problema suele descubrirse meses después.

pg_lsclusters

Una entrada para la versión 16 indica que ese clúster sigue usando 16. Si pg_lsclusters también muestra un clúster 18 main, confirme que esté vacío antes de eliminarlo con sudo pg_dropcluster --stop 18 main, porque pg_upgradecluster no escribirá en un clúster de destino que ya exista. Realice la migración cuando pueda detener la aplicación:

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

El método predeterminado vuelca 16 y carga los datos 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. El hook de actualización del paquete ejecuta automáticamente un análisis; el comando anterior lo repite de forma explícita.

Pruebe la aplicación contra 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 la actualización. No lo elimine el día de la actualización.

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

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

Primero, mysqld no arranca si su configuración contiene una opción que la nueva versión eliminó. default_authentication_plugin es la más habitual, porque muchas guías antiguas indican que debe configurarse. 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 usa no puede iniciar sesión. Compruébelo mientras aún utiliza 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 su 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 MySQL eliminó el plugin en 9.0.

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)

Apúntelo al nuevo socket, compruebe 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

En Apache con mod_php, el síntoma es diferente: Apache no se inicia y sudo apache2ctl -t indica 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 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.

La configuración de ajuste de php.ini tampoco se conserva. memory_limit, upload_max_filesize y cualquier otro valor que haya establecido 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 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 propia. Ejecute sudo certbot renew --dry-run --run-deploy-hooks 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. Un hook que llama a un nombre de servicio o a un binario que ha cambiado falla aquí, de forma visible, en lugar de fallar silenciosamente durante la siguiente renovación. 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 los usuarios 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 del paquete 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, para la mayoría de las opciones, OpenSSH conserva el primer valor que lee. Por tanto, un archivo adicional incluido al principio tiene prioridad sobre la misma opción definida más abajo. Algunas palabras clave son excepciones: Port y ListenAddress aceptan varios valores. Una línea Port en un archivo adicional añade un puerto en lugar de reemplazar el definido más abajo. Mueva sus opciones a un archivo que no pertenezca a dpkg:

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: cualquier respuesta conserva sus opciones 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 abre el puerto de escucha, no sshd. Ubuntu usa la activación mediante sockets para sshd desde 22.10. En 24.04, un generador de systemd lee las opciones Port y ListenAddress de la configuración de sshd y las convierte en las direcciones de escucha del socket, pero sólo cuando systemd vuelve a cargar sus unidades. Por eso una modificación de Port 2222 parece no tener efecto: se aplica después de sudo systemctl daemon-reload && sudo systemctl restart ssh.socket y el archivo sshd_config incluido en el paquete ahora contiene una nota que lo indica. Para definir directamente el puerto en la unidad de socket, use sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

El ListenStream= vacío es necesario. Elimina 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 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 comprobarlo. Refuerzo de la seguridad de SSH en un VPS explica las opciones 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. Esa consola es precisamente el motivo por el que 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?

Desde el 29 September 2026 no debería mostrarlo, porque ese día Canonical habilitó las actualizaciones de 24.04 LTS a 26.04.1. Antes de esa fecha, el mensaje era esperado: Ubuntu 26.04 LTS se publicó el 23 April 2026, 26.04.1 llegó el 27 August y la ruta permaneció cerrada unas semanas más mientras Canonical adaptaba correcciones para regresiones de rust-coreutils. Si sigue viéndolo, compruebe que /etc/update-manager/release-upgrades contenga Prompt=lts, el valor predeterminado de Ubuntu Server, que ofrece únicamente la siguiente versión de soporte a largo plazo. Déjelo en lts.

¿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 usando 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á ejecutando una mezcla de dos versiones. Cuando vuelva a estar disponible, compruebe uname -r para verificar el kernel nuevo y systemctl --failed para identificar los servicios que no se recuperaron.

¿Debo actualizar el servidor actual o crear un servidor 26.04 nuevo?

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 DNS en lugar de restaurar una copia de seguridad. Actualice el servidor actual cuando contenga estado difícil de migrar, cuando el proveedor facture por máquina o cuando tenga una instantánea y acceso de consola probado. La actualización sobre el sistema existente es un procedimiento conocido, pero durante la hora que dura es irreversible.

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

El actualizador del servidor normalmente usa GNU screen, por lo que una conexión SSH interrumpida no detiene por sí sola la actualización. Si la inició dentro de la sesión tmux indicada anteriormente, vuelva a conectarse y ejecute tmux attach -t upgrade para retomarla. El actualizador también inicia un daemon SSH auxiliar 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 ha roto?

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 lo que /run/php/php8.3-fpm.sock ya no existe mientras el vhost de nginx todavía la referencia. 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 consiste en ejecutar sudo a2dismod php8.3, después sudo a2enmod php8.5 y reiniciar.