Cuando un servidor Linux arranca pasa por varias fases encadenadas: el firmware, el gestor de arranque GRUB, el kernel, el initramfs y, por último, systemd. Si una falla, el sistema se queda parado en esa fase, y saber cuál es te dice qué tienes que reparar. En este tutorial recorrerás cada fase en Ubuntu 24.04 con los comandos que muestran su estado, configurarás GRUB e initramfs de forma segura y practicarás los procedimientos para recuperar un servidor que no arranca.
Requisitos previos
- Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
- Un usuario no root con privilegios
sudo. - Acceso a la consola del servidor (VNC o KVM del proveedor, o IPMI en un servidor dedicado). Los menús de GRUB y los modos de rescate no son accesibles por SSH.
- Para la recuperación con chroot, poder arrancar el servidor desde una ISO de rescate o una ISO Live de Ubuntu.
Advertencialos cambios en GRUB,
/etc/fstaby el initramfs pueden dejar el servidor sin arrancar. Haz una instantánea o copia de seguridad antes de practicar en un servidor con datos.
Las fases del arranque
| Fase | Qué ocurre | Síntoma típico si falla |
|---|---|---|
| 1. Firmware (BIOS o UEFI) | Comprueba el hardware y busca un disco o entrada de arranque | No bootable device |
| 2. GRUB | Lee grub.cfg, muestra el menú y carga el kernel y el initramfs | Prompt grub> o grub rescue> |
| 3. Kernel | Inicializa CPU, memoria y controladores básicos, y descomprime el initramfs | Kernel panic |
| 4. initramfs | Carga los módulos de disco, busca la partición raíz y la monta | Shell (initramfs) o Unable to mount root fs |
| 5. systemd | Se ejecuta como PID 1, monta /etc/fstab y arranca los servicios del target por defecto | emergency mode, servicios fallidos |
Paso 1: Identificar el firmware y el disco de arranque
Averigua si el sistema arrancó en modo UEFI o BIOS heredado. El directorio /sys/firmware/efi solo existe con UEFI:
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI
Muestra los discos y particiones con su sistema de ficheros y punto de montaje:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
NAME SIZE FSTYPE MOUNTPOINTS
vda 80G
├─vda1 79.9G ext4 /
├─vda14 4M
└─vda15 106M vfat /boot/efi
En esta disposición, típica de las imágenes cloud de Ubuntu, vda15 es la partición del sistema EFI (ESP), vda14 es la partición de arranque BIOS que permite arrancar en ambos modos y vda1 es la raíz. En modo UEFI, lista las entradas de arranque del firmware:
sudo apt install efibootmgr
sudo efibootmgr
BootCurrent: 0003
BootOrder: 0003,0001,0000
Boot0003* ubuntu HD(15,GPT,...)/File(\EFI\ubuntu\shimx64.efi)
shimx64.efi es el primer cargador firmado para Secure Boot, que a su vez carga GRUB.
Paso 2: Medir el arranque y leer sus registros
systemd registra lo que tarda cada fase y cada servicio:
systemd-analyze
Startup finished in 1.912s (kernel) + 7.305s (userspace) = 9.217s
graphical.target reached after 7.264s in userspace.
Para saber qué units retrasan el arranque, consulta la cadena crítica, que muestra solo lo que está en el camino más lento:
systemd-analyze critical-chain
Los registros de cada arranque se guardan en el journal. Ubuntu 24.04 los conserva en disco, así que puedes consultar también los arranques anteriores, lo que resulta clave para diagnosticar un fallo después de haber recuperado el servidor:
journalctl --list-boots --no-pager | tail -n 3
-2 8c1f... Tue 2026-09-23 08:11:02 UTC Tue 2026-09-23 19:40:13 UTC
-1 51ad... Tue 2026-09-23 19:41:10 UTC Thu 2026-09-25 08:59:48 UTC
0 e7b2... Thu 2026-09-25 09:00:41 UTC Thu 2026-09-25 10:22:05 UTC
Muestra los errores del arranque anterior y los mensajes del kernel del actual:
journalctl -b -1 -p err --no-pager
journalctl -k -b --no-pager | head -n 20
Los parámetros con los que arrancó el kernel están en /proc/cmdline:
cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0-85-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
Paso 3: Configurar GRUB
GRUB lee /boot/grub/grub.cfg, pero ese fichero se genera automáticamente y no debe editarse a mano. Los ajustes se hacen en /etc/default/grub y en los ficheros de /etc/default/grub.d/, que se leen después y tienen prioridad. En las imágenes cloud de Ubuntu existe /etc/default/grub.d/50-cloudimg-settings.cfg, que redefine el tiempo de espera y los parámetros del kernel. Comprueba qué ficheros tienes:
ls /etc/default/grub.d/
50-cloudimg-settings.cfg init-select.cfg
Para añadir tus ajustes sin que otro fichero los sobrescriba, crea uno propio con un número mayor:
sudo nano /etc/default/grub.d/99-local.cfg
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
Con esto, el menú de GRUB se muestra durante 5 segundos en cada arranque, lo que te da tiempo a elegir otro kernel o editar los parámetros desde la consola. Si necesitas parámetros del kernel adicionales, añádelos aquí con GRUB_CMDLINE_LINUX_DEFAULT, incluyendo también los que ya define el fichero de la imagen cloud, porque el valor se sustituye completo.
Las variables más importantes son:
GRUB_DEFAULT: la entrada que arranca por defecto.0es la primera;savedusa la última guardada congrub-set-defaultogrub-reboot.GRUB_TIMEOUTyGRUB_TIMEOUT_STYLE: cuánto tiempo y cómo se muestra el menú (menu,countdownohidden).GRUB_CMDLINE_LINUX: parámetros del kernel para todas las entradas, incluidas las de recuperación.GRUB_CMDLINE_LINUX_DEFAULT: parámetros solo para las entradas normales.
Regenera grub.cfg y revisa que no haya errores:
sudo update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/50-cloudimg-settings.cfg'
Sourcing file `/etc/default/grub.d/99-local.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-85-generic
Found initrd image: /boot/initrd.img-6.8.0-85-generic
done
Paso 4: Gestionar las versiones del kernel
Ubuntu conserva el kernel anterior al actualizar, así que si uno nuevo falla puedes volver al previo. Lista los kernels instalados y el que está en uso:
ls /boot/vmlinuz-*
uname -r
Para probar un kernel concreto solo en el siguiente reinicio, sin cambiar el predeterminado, usa grub-reboot. Necesita GRUB_DEFAULT=saved, así que añade esa línea a /etc/default/grub.d/99-local.cfg y regenera la configuración:
echo 'GRUB_DEFAULT=saved' | sudo tee -a /etc/default/grub.d/99-local.cfg
sudo update-grub
Obtén los nombres exactos de las entradas del submenú de opciones avanzadas:
sudo grep -E "menuentry '|submenu '" /boot/grub/grub.cfg | cut -d"'" -f2
Ubuntu
Advanced options for Ubuntu
Ubuntu, with Linux 6.8.0-85-generic
Ubuntu, with Linux 6.8.0-85-generic (recovery mode)
Ubuntu, with Linux 6.8.0-79-generic
Ubuntu, with Linux 6.8.0-79-generic (recovery mode)
Las entradas de un submenú se indican con la ruta submenú>entrada:
sudo grub-reboot 'Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-79-generic'
sudo reboot
Tras el reinicio, uname -r mostrará 6.8.0-79-generic, y el siguiente arranque volverá al predeterminado. Para fijarlo de forma permanente, usa grub-set-default con la misma ruta.
Paso 5: Inspeccionar y regenerar el initramfs
El initramfs es un pequeño sistema de ficheros comprimido que el kernel carga en memoria. Contiene los módulos y scripts necesarios para encontrar y montar la partición raíz real, por ejemplo controladores de disco, LVM, RAID o cifrado. Lista su contenido:
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio|ext4' | head -n 5
usr/lib/modules/6.8.0-85-generic/kernel/drivers/block/virtio_blk.ko.zst
usr/lib/modules/6.8.0-85-generic/kernel/fs/ext4/ext4.ko.zst
...
Debes regenerarlo cuando cambies algo que se necesita antes de montar la raíz: módulos en /etc/initramfs-tools/modules, la configuración de LVM o cryptsetup, o si sospechas que está dañado:
sudo update-initramfs -u -k $(uname -r)
update-initramfs: Generating /boot/initrd.img-6.8.0-85-generic
Con -k all se regeneran los de todos los kernels instalados. Si /boot está en una partición separada, comprueba antes que tiene espacio libre con df -h /boot, porque un initramfs a medio escribir por falta de espacio es una causa común de fallos de arranque.
Paso 6: Arrancar en modo rescate o emergencia
systemd ofrece dos targets mínimos para reparar el sistema desde la consola:
rescue.target: monta todos los sistemas de ficheros y arranca un shell de root sin red ni servicios.emergency.target: monta solo la raíz, en modo de solo lectura, y arranca un shell. Sirve cuando el problema está en/etc/fstab.
Para arrancar en uno de ellos, abre la consola del servidor, reinícialo y, en el menú de GRUB, sitúate sobre la entrada Ubuntu y pulsa e. Busca la línea que empieza por linux y añade al final:
systemd.unit=rescue.target
Pulsa Ctrl+X o F10 para arrancar con ese parámetro. El cambio solo afecta a este arranque.
Importanteambos modos piden la contraseña de root. En Ubuntu la cuenta root está bloqueada por defecto, y en ese caso el sistema muestra
Cannot open access to console, the root account is lockedy no deja entrar. Si no has definido una contraseña de root, usa el procedimiento del paso 7.
Si llegas al shell de emergencia, remonta la raíz en lectura y escritura para poder editar ficheros:
mount -o remount,rw /
Cuando termines, continúa el arranque normal con systemctl default o reinicia con systemctl reboot.
Paso 7: Recuperar el acceso con init=/bin/bash
Si has perdido la contraseña del usuario con sudo o la cuenta root está bloqueada, puedes pedir al kernel que ejecute un shell en lugar de systemd. En la línea linux de GRUB, añade al final:
init=/bin/bash
Arranca con Ctrl+X. Obtendrás un shell de root sin systemd, con la raíz montada en solo lectura. Remóntala en escritura y cambia la contraseña:
mount -o remount,rw /
passwd your_user
Como systemd no está en ejecución, reboot no funciona de la forma habitual. Vuelca los datos a disco, vuelve a montar la raíz en solo lectura y reinicia directamente con la interfaz sysrq del kernel:
sync
mount -o remount,ro /
echo b > /proc/sysrq-trigger
Advertenciaeste método da acceso de root a cualquiera con acceso a la consola. Protege el acceso a la consola del proveedor con contraseñas robustas y doble factor.
Paso 8: Reparar el sistema desde un chroot
Cuando GRUB está dañado, falta el kernel o el initramfs no monta la raíz, no hay menú al que volver. Arranca el servidor desde una ISO de rescate o una ISO Live de Ubuntu y trabaja sobre el disco con chroot.
Desde el sistema de rescate, identifica las particiones del disco del servidor:
lsblk -o NAME,SIZE,FSTYPE,LABEL
Monta la raíz y, si existe, la ESP. Sustituye los dispositivos por los tuyos:
sudo mount /dev/vda1 /mnt
sudo mount /dev/vda15 /mnt/boot/efi
Monta los sistemas de ficheros virtuales del kernel dentro de la raíz y entra en el chroot:
for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash
Dentro del chroot trabajas como si hubieras arrancado el servidor. Desde aquí puedes reparar las causas más comunes:
Reinstalar GRUB en un sistema UEFI con Secure Boot. En Ubuntu se hace reinstalando los paquetes firmados, que ejecutan grub-install con las opciones correctas:
apt install --reinstall grub-efi-amd64-signed shim-signed
update-grub
Reinstalar GRUB en un sistema BIOS, indicando el disco completo y no una partición:
grub-install /dev/vda
update-grub
Regenerar el initramfs de todos los kernels:
update-initramfs -u -k all
Comprobar que /etc/fstab es correcto y que sus UUID existen:
findmnt --verify
blkid
Al terminar, sal del chroot, desmonta todo y reinicia desde el disco:
exit
sudo umount -R /mnt
sudo reboot
Solución de problemas
El servidor entra en emergency mode tras editar /etc/fstab. Un disco que ya no existe o un UUID mal escrito bloquea el arranque. Entra en el shell de emergencia (o en un chroot), corrige la línea y valida con findmnt --verify. Añade la opción nofail a los discos de datos que no son imprescindibles para arrancar.
Kernel panic - not syncing: VFS: Unable to mount root fs. El kernel no encuentra o no puede montar la raíz. Arranca el kernel anterior desde el menú de GRUB; si funciona, regenera el initramfs del nuevo con update-initramfs -u -k versión. Si ninguno arranca, repáralo desde un chroot.
Aparece el prompt grub rescue>. GRUB no encuentra sus módulos ni su configuración, normalmente tras cambiar particiones o clonar el disco. Repáralo desde un chroot reinstalando GRUB como en el paso 8.
El servidor se queda en el shell (initramfs). El initramfs no encuentra el dispositivo de la raíz. Escribe cat /proc/cmdline y ls /dev/disk/by-uuid/ para comparar el valor de root= con los discos detectados. Suele deberse a un UUID cambiado o a un initramfs sin el controlador de disco; regénéralo desde un chroot.
Conclusión
Has recorrido las cinco fases del arranque de Ubuntu 24.04, has configurado GRUB con un fichero propio, has aprendido a arrancar un kernel concreto, a regenerar el initramfs y a recuperar un servidor con los targets de rescate, init=/bin/bash y un chroot. Como siguientes pasos, comprueba que tienes acceso a la consola de todos tus servidores antes de necesitarla, practica una recuperación con chroot en un servidor de pruebas y automatiza las copias de seguridad de /etc para restaurar configuraciones dañadas.