Curso de Ubuntu 26.04 / Recuperar fallos de arranque, kernel y red

Para recuperar Ubuntu, determine primero desde la consola qué fase falla y conserve los registros y cambios recientes. Que SSH no responda no demuestra que el sistema no haya arrancado: distinga el arranque, el kernel, la red y la aplicación antes de revertir una configuración. Para reunir evidencias, consulte Acotar la causa del fallo usando registros de Linux y Práctica integral de reproducir fallos y restaurar con evidencia.

Distinguir entre la etapa del fallo y los elementos a cambiar

Si es posible, conserve el estado antes de la recuperación y asegúrese de tener la copia de seguridad existente y la clave de desbloqueo. No dañe intencionalmente discos o la red del servidor de producción para prácticas. En el registro de la investigación, deje la hora·texto original del error·última operación exitosa·cambios recientes, y no incluya claves secretas ni información de autenticación.

Investigar en modo de solo lectura cuando sea posible iniciar sesión

cat /etc/os-release
uname -r
systemctl --failed
df -h
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

Si hay registros de arranque anteriores, compárelos con sudo journalctl -b -1 -p err --no-pager. El hecho de que no haya registros anteriores no es evidencia de que no hubo fallos. Aunque el disco esté lleno, no elimine los registros de forma masiva; verifique la causa y la ubicación de almacenamiento para conservar los registros necesarios. Si es difícil determinar la relación causal solo con las líneas de error, investigue los registros por unidad alrededor de ese momento.

Practicar fallos de servicios limitados y recuperación en máquinas virtuales de práctica

Se realiza iniciando sesión en la consola en la VM de práctica aislada del original. La siguiente nueva unidad no se activa al arrancar, ni elimina archivos ni cambia la red. Primero, verifique que se ejecute normalmente y luego cree un fallo intencionado usando drop-in con false, y solo elimine ese archivo para restaurarlo. Este ejercicio es una ruta de diagnóstico del servicio y no reproduce fallos reales del kernel o del arranque.

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop"; then
    printf 'Lab unit already exists; choose a new name.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Bounded Ubuntu recovery exercise
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo install -d -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Unexpected success: inspect the loaded unit.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

El resultado previsto de la primera ejecución es Result=success y ExecMainStatus=0; con el drop-in que ejecuta false, Result=exit-code y ExecMainStatus=1. Un fallo distinto al esperado requiere investigar su mensaje, no asumir que se reprodujo el caso previsto. Un servicio oneshot correcto sin RemainAfterExit puede quedar inactivo al terminar: compárelo con el resultado y el registro. Aplique la restauración solo si acaba de crear ese archivo y no hubo ediciones posteriores.

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-recovery-lab.service.d/10-failure.conf
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

Verifique nuevamente si es success·0. Para limpiar completamente, verifique si la unidad es este archivo de práctica y su estado de desactivación, luego elimine únicamente el directorio drop-in vacío y la unidad y ejecute daemon-reload. La determinación del kernel anterior o del modo de recuperación en caso de una falla real de arranque debe registrarse de manera separada según el siguiente procedimiento.

Comprobar el fallo de arranque y el kernel anterior después de la actualización

Si el arranque falla inmediatamente después de la actualización y puede acceder a GRUB y al kernel anterior, pruebe a arrancar seleccionando el kernel anterior en la opción Avanzada para Ubuntu de la consola. La forma de mostrar GRUB varía según el firmware, el host y el momento, por lo que debe verificar el método de manipulación de arranque en la consola de la VM o del dispositivo. Los discos encriptados aún requieren ser desbloqueados.

Si inicia con el kernel anterior, registre uname -r y compare el historial de actualizaciones, los registros y los controladores, incluidos los módulos gestionados por DKMS (Dynamic Kernel Module Support). Ese resultado orienta el diagnóstico, pero no demuestra por sí solo que el nuevo kernel sea la única causa. Conserve el kernel en ejecución y otro conocido como funcional mientras corrige la causa y comprueba el arranque.

En la guía del modo de recuperación de Ubuntu Wiki puede verificar el menú de recuperación de GRUB y los requisitos previos.

Distinguir la herramienta de disco RAM inicial

Ubuntu 26.04 utiliza Dracut como infraestructura predeterminada del entorno inicial de arranque o initramfs, tras el cambio introducido en 25.10. initramfs-tools sigue admitido y puede permanecer en una instalación concreta. Antes de regenerar imágenes con instrucciones de otra versión LTS, compruebe las herramientas instaladas y los archivos reales de /boot.

dpkg-query -W dracut dracut-core initramfs-tools 2>/dev/null
command -v dracut update-initramfs
ls -lh /boot

El simple hecho de que la herramienta esté instalada no significa que la imagen de arranque actual haya sido creada con esa herramienta. Verifique la configuración correspondiente a cifrado, LVM, RAID y al kernel elegido, así como la guía oficial de recuperación, y conserve el kernel, la consola y la copia de seguridad normales antes de regenerar.

Explicación del cambio a Dracut en Ubuntu 26.04

Permitir escritura después de verificar incluso en modo de recuperación

El shell root del menú de recuperación tiene privilegios elevados y es diferente de un inicio de sesión normal. Primero, verifique el reconocimiento del disco, el espacio disponible, el estado de montaje y los archivos que se van a modificar. Si el sistema de archivos raíz es de solo lectura y se necesita escritura para modificar la configuración real, considere los siguientes pasos en el shell de recuperación.

findmnt /
mount -o remount,rw /

En el shell de recuperación se ejecuta como root, por lo que no se ha utilizado sudo. Si hay daños en el sistema de archivos o errores de entrada/salida, no repita la escritura y priorice la conservación de los datos y los procedimientos estructurados según la configuración. No ejecute fsck en modo de modificación en sistemas de archivos montados ni inicialice discos cuyo destino sea incierto.

Cuando se pierde la conexión después de cambiar la configuración de red

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

En la consola, verifique la interfaz real, el gestor de red y la configuración válida de Netplan. Compare el archivo que se modificó más recientemente con la copia de seguridad anterior y no intente sobrescribir agregando un archivo YAML con otro nombre. También verifique si la configuración fue generada por cloud-init, entre otros.

Al restaurar desde una copia de seguridad correcta, conserve también la configuración actual y, después de que sudo netplan generate haya tenido éxito y la consola esté asegurada, use "sudo netplan try --timeout 120". La recuperación automática podría fallar, por lo que verifique por separado la dirección real, la ruta, el DNS y la nueva conexión SSH. Si la red funciona correctamente, también investigue individualmente la clave SSH y los puertos de escucha y la UFW.

Consulte el manual de 26.04 para conocer las limitaciones de netplan try y los elementos a verificar después de la recuperación.

Evaluar la conservación de datos y la finalización de la recuperación

Si no puede operar en el sistema operativo instalado, revise un entorno de recuperación verificado como un Live ISO. Antes de acceder al disco, verifique cifrado, LVM y RAID, y no seleccione el original como destino de instalación por error. No ejecute comandos de reinstalación genérica de GRUB o de recreación de particiones por conjeturas; seleccione procedimientos adecuados a la configuración real y copias de seguridad verificadas.

Después de la recuperación, se verifica el reinicio, la nueva conexión SSH, los servicios, la lectura y escritura de las aplicaciones, los registros y las copias de seguridad. Se registran lo que se ha restaurado y mejorado, los asuntos pendientes y los registros a recopilar en caso de recurrencia. El criterio para considerar la recuperación completa es si se puede mantener la operación normal más allá del momento en que se recibe la respuesta.