Cómo reparar Linux cuando no inicia: recuperar GRUB, kernel y archivos paso a paso

Enciendes el equipo, esperas que aparezca Linux y en lugar del escritorio encuentras una pantalla negra, GRUB Rescue, BusyBox, un kernel panic o simplemente un cursor parpadeando. Aunque la situación puede parecer grave, en muchos casos el sistema operativo y tus archivos continúan intactos.

Un cargador de arranque dañado, un kernel que no terminó correctamente de instalarse, una imagen initramfs corrupta, un error en /etc/fstab o un sistema de archivos inconsistente pueden impedir que Linux arranque sin que eso signifique necesariamente que debas formatear el equipo.

Con un USB Live de Linux, algunas herramientas básicas y siguiendo un orden correcto de diagnóstico, es posible recuperar una gran cantidad de instalaciones de Ubuntu, Debian, Linux Mint, Arch Linux, Fedora, Rocky Linux, AlmaLinux y otras distribuciones.

Lo primero es evitar actuar impulsivamente.

No reinstales Linux y no formatees el disco antes de comprobar si la instalación y tus datos todavía pueden recuperarse.

Puede leer también | Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers

Antes de reparar, identifica exactamente dónde se detiene Linux

No todos los problemas de arranque son iguales.

El proceso puede imaginarse así:

Encender computadora
        |
        v
BIOS / UEFI
        |
        v
GRUB
        |
        v
Kernel Linux
        |
        v
initramfs
        |
        v
Sistema raíz
        |
        v
systemd
        |
        v
Servicios
        |
        v
Escritorio / Login

Identificar en qué punto aparece el error puede ahorrar mucho tiempo.

Mensaje o síntoma	Posible problema
No aparece GRUB	Bootloader, EFI o configuración del firmware
grub rescue>	GRUB no encuentra sus módulos o partición
Kernel panic	Kernel, initramfs, módulos o dispositivo raíz
BusyBox / initramfs	Sistema raíz no encontrado o sistema de archivos dañado
Failed to mount...	Error en fstab, disco o UUID
Emergency mode	Montaje, filesystem o servicio crítico
Pantalla negra después de GRUB	Kernel, GPU, controlador o display manager
GRUB aparece pero Linux no inicia	Kernel o initramfs

Paso 1: no empieces reparando, empieza salvando tus archivos

Si existen documentos importantes y no tienes una copia reciente, antes de modificar GRUB, paquetes o sistemas de archivos conviene recuperar primero la información.

Arranca el equipo utilizando un USB Live de Ubuntu, Debian, Linux Mint, Fedora o cualquier distribución capaz de reconocer tus discos.

Después abre una terminal y ejecuta:

lsblk -f

También puedes utilizar:

sudo fdisk -l

y:

sudo blkid

Busca una partición Linux de tipo:

ext4
btrfs
xfs

Por ejemplo:

NAME        FSTYPE  SIZE  MOUNTPOINT
nvme0n1
├─nvme0n1p1 vfat    512M
├─nvme0n1p2 ext4     80G
└─nvme0n1p3 ext4    400G

En este escenario:

nvme0n1p1 -> EFI
nvme0n1p2 -> Linux /
nvme0n1p3 -> posiblemente /home

Monta la partición sin modificarla innecesariamente

Crea un punto de montaje:

sudo mkdir -p /mnt/linux

Después:

sudo mount /dev/nvme0n1p2 /mnt/linux

Comprueba:

ls /mnt/linux

Si aparecen directorios como:

bin
boot
etc
home
usr
var

probablemente encontraste la partición raíz correcta.

Recupera primero los documentos importantes

Conecta un disco USB externo.

Supongamos que aparece montado en:

/media/ubuntu/Backup

Puedes copiar el directorio personal utilizando:

rsync -aHAX --info=progress2 \
/mnt/linux/home/usuario/ \
/media/ubuntu/Backup/usuario/

O, para algo más sencillo:

cp -a /mnt/linux/home/usuario /media/ubuntu/Backup/

Antes de comenzar una reparación compleja, tener los datos importantes fuera del equipo elimina gran parte del riesgo.

Paso 2: comprueba si el disco sigue apareciendo

Si lsblk no muestra el SSD o disco donde estaba Linux, probablemente no estamos ante un problema de GRUB.

Debemos revisar:

• BIOS o UEFI.
• Cables SATA.
• SSD NVMe.
• Alimentación.
• Estado del dispositivo.

Si el disco aparece, comprueba su estado SMART cuando sea compatible.

Instala smartmontools si es necesario:

sudo apt install smartmontools

Después:

sudo smartctl -a /dev/sda

Para determinados NVMe:

sudo smartctl -a /dev/nvme0

Presta atención a errores graves, sectores defectuosos, errores de medios o advertencias críticas.

Un disco que está fallando debe copiarse antes de repararse

Si el dispositivo presenta errores físicos, ejecutar repetidamente herramientas de reparación puede empeorar la situación.

La prioridad cambia a:

Disco dañado
    |
    v
copiar o clonar
    |
    v
trabajar sobre copia

En recuperaciones delicadas suele utilizarse GNU ddrescue para intentar rescatar primero la mayor cantidad posible del dispositivo.

No confundas:

dd

con:

ddrescue

cuando estás trabajando con un disco físicamente inestable.

Paso 3: si GRUB aparece, prueba primero un kernel anterior

Este es uno de los métodos más sencillos y efectivos después de una actualización problemática.

En GRUB busca:

Advanced options for Ubuntu

o una entrada equivalente.

Podrías encontrar:

Ubuntu, with Linux 6.x.x-new
Ubuntu, with Linux 6.x.x-old

Selecciona el kernel anterior.

Si Linux inicia correctamente, probablemente el sistema base está bien y el problema está relacionado con:

• Nuevo kernel.
• Módulo.
• Controlador gráfico.
• initramfs.
• DKMS.

Si el kernel anterior funciona, no reinstales todo Linux

Arranca con el kernel funcional y comprueba:

uname -r

Después revisa los kernels instalados.

En Debian o Ubuntu:

dpkg -l 'linux-image*'

Si sospechas que una actualización quedó incompleta:

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install

Después puedes reinstalar el metapaquete correspondiente.

En Ubuntu:

sudo apt install --reinstall linux-generic

El nombre exacto puede cambiar dependiendo de la variante y arquitectura utilizada.

Paso 4: reconstruye initramfs

El initramfs es una pequeña imagen cargada inicialmente en memoria que contiene herramientas y módulos necesarios para encontrar y montar el sistema raíz.

Si está corrupta puedes encontrar mensajes como:

Unable to find root device

ALERT! UUID=... does not exist

Gave up waiting for root file system device

BusyBox
(initramfs)

En Debian, Ubuntu y distribuciones relacionadas puedes reconstruir las imágenes mediante:

sudo update-initramfs -u -k all

Y después regenerar GRUB:

sudo update-grub

En Arch Linux se utiliza mkinitcpio

Dentro de una instalación Arch:

sudo mkinitcpio -P

Esto reconstruye las imágenes basándose en todos los presets disponibles.

Si utilizas el kernel estándar y quieres regenerar únicamente ese preset:

sudo mkinitcpio -p linux

Fedora y RHEL utilizan normalmente dracut

En Fedora, RHEL, Rocky Linux y AlmaLinux es habitual regenerar initramfs con:

sudo dracut --force

Si necesitas reconstruir para un kernel específico, consulta primero:

ls /lib/modules/

y utiliza la versión apropiada según tu distribución.

Paso 5: si entras en BusyBox, comprueba primero el dispositivo raíz

Cuando aparece:

(initramfs)

puedes comenzar comprobando qué dispositivos reconoce el sistema:

blkid

y:

ls /dev/sd*

o, para NVMe:

ls /dev/nvme*

Si la partición raíz aparece pero no puede montarse, puede existir un error de filesystem.

Un error típico puede ser simplemente un sistema de archivos inconsistente

Después de un apagón o una desconexión repentina puede aparecer algo parecido a:

UNEXPECTED INCONSISTENCY;
RUN fsck MANUALLY

En un sistema ext4 puede ser necesario ejecutar:

fsck /dev/nvme0n1p2

o directamente:

e2fsck /dev/nvme0n1p2

No ejecutes e2fsck sobre un filesystem ext4 montado en modo lectura/escritura.

Lo apropiado es hacerlo desde un Live USB o sobre una partición desmontada.

Paso 6: revisa /etc/fstab

Otro problema frecuente aparece después de:

• Cambiar discos.
• Clonar una instalación.
• Crear nuevas particiones.
• Eliminar un disco secundario.
• Modificar UUID.

El sistema puede detenerse mostrando:

A start job is running for /dev/disk/by-uuid/...

Failed to mount...

You are in emergency mode

Arranca mediante Live USB, monta Linux y abre:

sudo nano /mnt/linux/etc/fstab

Compara los UUID registrados con:

sudo blkid

Por ejemplo:

fstab:

UUID=AAAA-BBBB /datos ext4 defaults 0 2


blkid:

UUID="CCCC-DDDD"

Si el UUID ya no existe, systemd puede esperar un dispositivo imposible de encontrar.

No elimines líneas de fstab sin entender para qué sirven

Si identificas una unidad secundaria que fue eliminada definitivamente, puedes comentar temporalmente su línea:

# UUID=AAAA-BBBB /datos ext4 defaults 0 2

Después vuelve a probar el arranque.

Para discos no esenciales también puede evaluarse la opción:

nofail

cuando el diseño del sistema permita continuar arrancando aunque el dispositivo no esté disponible.

Paso 7: reparar GRUB desde un USB Live

Si Linux está intacto pero GRUB desapareció, una de las formas más fiables de recuperarlo es entrar a la instalación mediante chroot.

Primero arranca un Live USB en el mismo modo de firmware utilizado por la instalación.

Si Linux fue instalado mediante UEFI, arranca el USB también mediante UEFI.

Compruébalo desde la sesión Live:

ls /sys/firmware/efi

Si ese directorio existe, el Live USB está arrancado en modo UEFI.

Identifica las particiones

Ejecuta:

lsblk -f

Supongamos:

/dev/nvme0n1p1 -> EFI
/dev/nvme0n1p2 -> /

Monta la raíz:

sudo mount /dev/nvme0n1p2 /mnt

Si tienes una partición /boot separada, también debes montarla

Por ejemplo:

sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p3 /mnt/boot

Los dispositivos concretos dependen totalmente del esquema del equipo.

En UEFI debes montar también la partición EFI

Una ubicación habitual es:

/boot/efi

Por ejemplo:

sudo mount /dev/nvme0n1p1 /mnt/boot/efi

Sin embargo, algunas distribuciones montan la ESP directamente en /boot. Comprueba siempre el /etc/fstab de tu sistema antes de asumir la ruta.

Monta los pseudo sistemas necesarios para chroot

Una forma habitual es:

for i in /dev /dev/pts /proc /sys /run; do
    sudo mount --bind $i /mnt$i
done

Después:

sudo chroot /mnt

Tu terminal está ahora trabajando como si hubieras iniciado el Linux instalado.

Comprueba antes de tocar GRUB

Dentro del chroot ejecuta:

ls /boot

Deberías encontrar archivos similares a:

vmlinuz-...
initrd.img-...
grub/

También comprueba:

cat /etc/os-release

Así te aseguras de que realmente estás dentro de la instalación correcta.

Reparar GRUB en Ubuntu, Debian y Linux Mint con BIOS heredado

En sistemas BIOS/MBR tradicionales puede utilizarse:

grub-install /dev/sda
update-grub

Importante:

/dev/sda  -> disco

/dev/sda1 -> partición

En una instalación BIOS habitual, GRUB se instala sobre el dispositivo correspondiente, no sobre una partición arbitraria.

Reparar GRUB en sistemas UEFI

Si la ESP está montada correctamente en:

/boot/efi

una instalación genérica de GRUB x86-64 puede utilizar:

grub-install \
--target=x86_64-efi \
--efi-directory=/boot/efi \
--bootloader-id=GRUB

Después:

update-grub

En Ubuntu con Secure Boot y paquetes gestionados por la distribución puede ser preferible reinstalar los paquetes de GRUB y shim correspondientes en lugar de improvisar una instalación EFI manual.

No copies comandos UEFI sin comprobar dónde está montada tu ESP

Este es uno de los errores más frecuentes de las guías rápidas.

Un sistema puede utilizar:

/boot/efi

/efi

/boot

como punto de montaje.

Antes de ejecutar grub-install comprueba:

cat /etc/fstab

y:

findmnt

Un comando correcto con una ruta incorrecta sigue siendo un comando incorrecto.

Arch Linux utiliza grub-mkconfig

Dentro de arch-chroot, una instalación UEFI típica puede utilizar:

grub-install \
--target=x86_64-efi \
--efi-directory=/boot/efi \
--bootloader-id=GRUB

si ése es realmente el punto donde está montada la partición EFI.

Después:

grub-mkconfig -o /boot/grub/grub.cfg

Arch recomienda ejecutar estas operaciones desde el propio sistema instalado o después de entrar mediante arch-chroot.

En Fedora y RHEL los nombres de comandos son diferentes

En la familia Fedora/RHEL encontrarás normalmente:

grub2-mkconfig

en lugar de:

grub-mkconfig

En versiones actuales de RHEL, el archivo principal generado se mantiene normalmente en:

/boot/grub2/grub.cfg

incluso en instalaciones UEFI modernas, mientras la ubicación EFI puede contener archivos auxiliares o stubs.

Por eso conviene seguir la documentación correspondiente a la versión exacta de Fedora, RHEL, Rocky Linux o AlmaLinux utilizada.

Paso 8: reparar un grub rescue> manualmente

En algunos casos aparece únicamente:

grub rescue>

Esto indica que parte de GRUB se ejecutó, pero no encuentra los componentes necesarios para mostrar el menú normal.

Empieza con:

ls

Podrías recibir:

(hd0)
(hd0,gpt1)
(hd0,gpt2)
(hd0,gpt3)

Explora las particiones:

ls (hd0,gpt2)/

Busca aquella que contenga:

boot/
etc/
home/
usr/

o una partición separada que contenga directamente:

grub/
vmlinuz...
initramfs...

Si encuentras /boot/grub, intenta recuperar el modo normal

Por ejemplo:

set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
insmod normal
normal

Si GRUB aparece y consigues iniciar Linux, debes hacer la reparación permanente posteriormente.

En Debian o Ubuntu:

sudo grub-install /dev/sda
sudo update-grub

adaptándolo a BIOS o UEFI según corresponda.

No confundas una solución temporal con una reparación permanente

Los comandos ejecutados en:

grub>

o:

grub rescue>

normalmente afectan únicamente a ese arranque.

Una vez dentro de Linux debes reparar la instalación y regenerar el archivo de configuración.

Paso 9: comprobar si /boot está lleno

Este problema es mucho más común de lo que parece.

Una actualización intenta instalar un kernel nuevo y falla porque:

/boot

se quedó sin espacio.

Después el sistema puede quedar con:

• Kernel incompleto.
• initramfs incompleto.
• GRUB apuntando a archivos inconsistentes.

Comprueba:

df -h /boot

Y lista los kernels:

ls -lh /boot

No borres kernels manualmente con rm salvo que sepas exactamente lo que haces

En distribuciones administradas mediante paquetes, es preferible eliminar kernels antiguos mediante el gestor correspondiente.

En Ubuntu:

sudo apt autoremove

Pero antes:

uname -r

para identificar el kernel actualmente utilizado.

Nunca elimines el único kernel que sabes que funciona.

Paso 10: reinstalar el kernel si sus archivos están incompletos

Si faltan archivos en /boot o una actualización quedó interrumpida, puede ser necesario reinstalar el kernel.

En Ubuntu:

sudo apt install --reinstall linux-image-$(uname -r)

Esto funciona cuando has arrancado utilizando exactamente el kernel afectado.

Si estás dentro de chroot y no coincide con el kernel del Live USB, identifica primero los paquetes instalados:

dpkg -l 'linux-image*'

Después reinstala la versión necesaria.

En Arch puede reinstalarse el paquete linux

Dentro de arch-chroot:

pacman -S linux

o, si utilizas otro kernel:

pacman -S linux-lts

La instalación del paquete genera normalmente la imagen initramfs correspondiente.

En Fedora o RHEL utiliza DNF

Puedes comprobar los kernels instalados mediante:

rpm -qa 'kernel*'

y utilizar DNF para reinstalar o reparar los paquetes correspondientes según la versión de la distribución.

Paso 11: Kernel panic después de una actualización

Un mensaje:

Kernel panic - not syncing

puede tener muchas causas.

Algunas de las más frecuentes son:

• initramfs incorrecto.
• Kernel incompleto.
• Módulo de almacenamiento ausente.
• UUID de root incorrecto.
• Problema con LUKS, LVM o RAID.
• Hardware defectuoso.

Antes de realizar cambios complejos, prueba un kernel anterior desde GRUB.

Si funciona, el diagnóstico se reduce enormemente.

Comprueba que kernel e initramfs existan juntos

Dentro de:

/boot

puedes encontrar:

vmlinuz-6.x.x
initrd.img-6.x.x

Ambos deben corresponder adecuadamente.

Si tienes:

vmlinuz-nuevo

pero no:

initrd.img-nuevo

la actualización probablemente quedó incompleta.

Paso 12: comprobar UUID incorrectos

GRUB y el sistema pueden localizar particiones mediante UUID.

Comprueba los actuales:

blkid

Después revisa:

/etc/fstab

y, cuando corresponda:

/boot/grub/grub.cfg

Normalmente no deberías editar manualmente grub.cfg.

Corrige la fuente correspondiente y regenera el archivo mediante:

update-grub

o:

grub-mkconfig -o /boot/grub/grub.cfg

dependiendo de la distribución.

Paso 13: sistemas cifrados con LUKS

Si Linux utiliza cifrado de disco, la partición raíz no aparecerá directamente como ext4 o Btrfs.

Podrías observar:

/dev/nvme0n1p3 crypto_LUKS

Para abrirla desde Live USB:

sudo cryptsetup open /dev/nvme0n1p3 cryptroot

Después aparecerá:

/dev/mapper/cryptroot

que podrá montarse si contiene directamente el filesystem.

Si dentro existe LVM, todavía debes activar los volúmenes lógicos.

LVM necesita un paso adicional

Después de desbloquear LUKS:

sudo vgchange -ay

Después:

sudo lvs

Podrías obtener:

/dev/mapper/vgubuntu-root
/dev/mapper/vgubuntu-home

Entonces monta el volumen raíz:

sudo mount /dev/mapper/vgubuntu-root /mnt

y continúa con el procedimiento de chroot.

Paso 14: Btrfs necesita conocer los subvolúmenes

En sistemas Btrfs modernos, montar únicamente la partición puede no reproducir la estructura real utilizada durante el arranque.

Comprueba:

sudo btrfs subvolume list /mnt

Un esquema frecuente puede contener:

@
@home
@log
@snapshots

En ese caso la raíz podría necesitar montarse como:

sudo mount -o subvol=@ /dev/nvme0n1p2 /mnt

y los demás subvolúmenes en sus puntos correspondientes antes de entrar a chroot.

Btrfs puede darte una ventaja: snapshots

Si utilizas herramientas como:

• Snapper.
• Timeshift.

podrías disponer de un snapshot anterior a la actualización problemática.

El esquema ideal sería:

actualización rompe sistema
        |
        v
snapshot anterior
        |
        v
rollback

Esto puede ser mucho más rápido que investigar manualmente cada paquete modificado.

Paso 15: pantalla negra después de que GRUB funciona

Si GRUB inicia Linux, pero después aparece una pantalla negra, el problema probablemente no sea GRUB.

En el menú selecciona la entrada de Linux y presiona:

e

Busca la línea que empieza por:

linux

Para probar un problema gráfico, en determinados escenarios puede añadirse temporalmente:

nomodeset

al final de la línea.

Arranca con:

Ctrl + X

o:

F10

según la versión de GRUB.

Si el sistema inicia, probablemente debas revisar:

• Drivers NVIDIA.
• AMDGPU.
• Controladores Intel.
• DKMS.
• Wayland/Xorg.

nomodeset es una herramienta de diagnóstico, no una solución definitiva

Puede permitir iniciar con gráficos básicos, pero no debería utilizarse permanentemente sin investigar por qué el controlador normal no funciona.

Paso 16: intenta entrar en una consola de texto

Si la pantalla gráfica falla, prueba:

Ctrl + Alt + F3

o:

Ctrl + Alt + F2

Si aparece un login, Linux probablemente inició correctamente y el problema está limitado al escritorio.

Después de entrar:

systemctl status display-manager

También:

journalctl -b -p err

Esto muestra errores del arranque actual.

Los logs pueden decir exactamente qué componente falló

Para el arranque actual:

journalctl -b

Solo errores:

journalctl -b -p err

Arranque anterior:

journalctl -b -1

Kernel:

journalctl -k

Buscar un servicio concreto:

journalctl -u NetworkManager

o:

journalctl -u display-manager

Paso 17: modo de emergencia de systemd

Si aparece:

You are in emergency mode

systemd logró iniciar parcialmente el sistema, lo que facilita el diagnóstico.

Ejecuta:

journalctl -xb

Busca especialmente:

Failed to mount

Dependency failed

Timed out waiting

fsck failed

Después comprueba:

systemctl --failed

Paso 18: comprobar si el disco raíz se quedó sin espacio

Linux puede arrancar mal simplemente porque:

/

o:

/var

alcanzaron el 100%.

Comprueba:

df -h

y los inodos:

df -i

Un filesystem puede tener gigabytes libres y aun así no permitir crear nuevos archivos porque agotó sus inodos.

Encuentra qué está ocupando espacio

Desde el sistema o chroot:

du -xhd1 /var | sort -h

También:

du -xhd1 / | sort -h

Áreas habituales:

• /var/log
• /var/cache
• /var/lib/docker
• /var/lib/containers
• /tmp

No borres directorios completos para conseguir espacio rápidamente

Eliminar algo como:

/var/lib

puede destruir bases de datos, contenedores y estados de aplicaciones.

Identifica primero qué servicio creó los archivos.

Una guía rápida según el mensaje que aparece

Problema	Primera acción
grub rescue>	Buscar partición GRUB y después reinstalar desde Live USB
No aparece GRUB	Revisar UEFI y reinstalar bootloader
Kernel panic	Probar kernel anterior
BusyBox/initramfs	Revisar root, filesystem e initramfs
Emergency mode	Revisar journal y fstab
Failed to mount	Comparar UUID de fstab con blkid
Pantalla negra	Probar consola y revisar GPU
/boot lleno	Arrancar kernel funcional y limpiar paquetes antiguos
Disco no aparece	Diagnóstico de hardware antes de reparar Linux

El procedimiento universal de recuperación mediante Live USB

Si no sabes exactamente qué está roto, este flujo permite acceder a una gran cantidad de instalaciones Linux.

1. Arrancar USB Live

2. lsblk -f

3. Identificar /

4. Montar /

5. Montar /boot si existe separado

6. Montar EFI si corresponde

7. Montar /dev /proc /sys /run

8. Entrar a chroot

9. Revisar:
   kernel
   initramfs
   grub
   fstab
   paquetes

10. Reparar

11. Salir

12. Desmontar

13. Reiniciar

Ejemplo completo para Ubuntu/Debian UEFI

Este ejemplo debe adaptarse a las particiones reales de tu equipo.

sudo mount /dev/nvme0n1p2 /mnt

sudo mount /dev/nvme0n1p1 /mnt/boot/efi

for i in /dev /dev/pts /proc /sys /run; do
    sudo mount --bind $i /mnt$i
done

sudo chroot /mnt

update-initramfs -u -k all

grub-install \
--target=x86_64-efi \
--efi-directory=/boot/efi \
--bootloader-id=GRUB

update-grub

exit

Después desmonta en orden inverso o reinicia desde el entorno Live cuando todo haya terminado correctamente.

Ejemplo general BIOS

sudo mount /dev/sda2 /mnt

for i in /dev /dev/pts /proc /sys /run; do
    sudo mount --bind $i /mnt$i
done

sudo chroot /mnt

update-initramfs -u -k all

grub-install /dev/sda

update-grub

exit

Observa nuevamente que:

/dev/sda

representa el disco en este ejemplo.

¿Y si Windows desaparece del menú GRUB?

Si Linux inicia pero Windows dejó de aparecer, estamos ante un problema diferente.

Primero comprueba que la partición Windows continúa existiendo:

lsblk -f

En determinadas distribuciones puede utilizarse os-prober para localizar otros sistemas operativos.

Después debe regenerarse la configuración de GRUB.

No reinstales Windows ni modifiques sus particiones simplemente porque no aparezca en el menú.

Secure Boot puede cambiar el procedimiento

En equipos UEFI con Secure Boot, el proceso de arranque puede incluir:

Firmware
   |
   v
shim
   |
   v
GRUB firmado
   |
   v
kernel firmado

Instalar manualmente un GRUB diferente o un kernel no firmado puede provocar que el firmware rechace la cadena.

En Ubuntu, Fedora y otras distribuciones que gestionan Secure Boot, utiliza preferentemente sus propios paquetes y procedimientos antes de reemplazar manualmente binarios EFI.

¿Cuándo debería dejar de reparar y pensar en reinstalar?

Reinstalar puede ser razonable cuando:

• La instalación tiene años de problemas acumulados.
• El sistema de paquetes está profundamente dañado.
• Existen muchas modificaciones desconocidas.
• Ya recuperaste los archivos importantes.
• Una instalación limpia tarda menos que reconstruir el sistema.

Pero incluso entonces conviene separar:

reinstalar el sistema operativo

de:

perder los datos.

Un sistema que no arranca todavía puede permitir recuperar prácticamente todo el contenido de /home.

Qué archivos deberías salvar antes de reinstalar

Para un equipo personal:

• /home
• Documentos.
• Fotografías.
• Proyectos.
• Claves SSH.
• Configuraciones importantes.

Para un servidor:

• /etc
• Datos de aplicaciones.
• Bases de datos exportadas.
• Configuraciones de Nginx o Apache.
• Docker Compose.
• Certificados.
• Crontabs.
• Datos de usuarios.

La ubicación exacta depende completamente de los servicios instalados.

Qué NO deberías hacer durante una recuperación

• Formatear antes de recuperar los datos.
• Ejecutar comandos encontrados al azar sin entender los dispositivos.
• Ejecutar fsck sobre ext4 montado en lectura/escritura.
• Instalar GRUB en un disco diferente por error.
• Eliminar kernels manualmente sin conocer el que funciona.
• Modificar fstab sin conservar una copia.
• Ejecutar comandos destructivos sobre un disco físicamente defectuoso.
• Asumir que UEFI y BIOS utilizan exactamente el mismo procedimiento.

Antes de editar, crea una copia

Por ejemplo:

cp /etc/fstab /etc/fstab.backup

Para GRUB:

cp /etc/default/grub /etc/default/grub.backup

Es una práctica sencilla que permite volver rápidamente al punto anterior.

Cómo evitar que el próximo problema se convierta en una emergencia

Un sistema Linux bien administrado debería contar con varias capas de recuperación.

Linux
 |
 +-- kernel actual
 |
 +-- kernel anterior
 |
 +-- snapshots
 |
 +-- backup
 |
 +-- Live USB
 |
 +-- documentación

Mantén por lo menos un kernel anterior funcional

Eliminar inmediatamente todos los kernels antiguos ahorra poco espacio y elimina una excelente herramienta de recuperación.

Si una actualización rompe el controlador de almacenamiento o GPU, un kernel anterior puede permitir iniciar el sistema en segundos.

Los snapshots no sustituyen los backups

Un snapshot Btrfs o LVM puede resultar excelente frente a:

• Actualización rota.
• Configuración incorrecta.
• Paquete problemático.

Pero si el SSD falla físicamente:

disco
 |
 +-- sistema
 +-- snapshot

puedes perder ambos.

Por eso:

snapshot != backup

Mantén un USB Live preparado

No necesitas esperar a que Linux falle para descubrir que no tienes otra computadora disponible para descargar una imagen.

Un USB de recuperación puede contener:

• Ubuntu Live.
• SystemRescue.
• Arch ISO.
• Rescuezilla.

Lo importante es saber arrancarlo y acceder a tus discos.

Un backup de /etc puede ahorrar horas

En un servidor, conservar:

/etc

permite recuperar configuraciones de:

• SSH.
• Red.
• systemd.
• Nginx.
• Apache.
• Firewall.
• Servicios.

No siempre debe restaurarse todo el directorio sobre una instalación nueva, pero disponer de la referencia es extremadamente útil.

Para servidores, documenta la partición EFI y el esquema de discos

Cuando un servidor falla no es el mejor momento para descubrir que nadie sabe cuál de cuatro discos contiene GRUB.

Conviene documentar:

Elemento	Ejemplo
Disco sistema	/dev/nvme0n1
Root	/dev/nvme0n1p2
EFI	/dev/nvme0n1p1
Filesystem	ext4
Bootloader	GRUB UEFI
Cifrado	LUKS
LVM	vg0/root

Checklist rápido de recuperación

1. No formatear.
2. Arrancar desde un USB Live.
3. Comprobar que el disco existe.
4. Identificar las particiones con lsblk -f.
5. Salvar primero los archivos importantes.
6. Comprobar el estado SMART del disco.
7. Intentar arrancar un kernel anterior.
8. Revisar el sistema de archivos si corresponde.
9. Comprobar UUID y fstab.
10. Montar la instalación.
11. Entrar mediante chroot.
12. Reconstruir initramfs.
13. Reinstalar o regenerar GRUB.
14. Reinstalar kernel si es necesario.
15. Revisar espacio libre.
16. Comprobar logs.
17. Reiniciar.
18. Crear backup después de recuperar el sistema.

Recomendamos

• Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
• Las mejores herramientas de código abierto para proteger su servidor Linux
• Cómo instalar diferentes tipos de paquetes en distribuciones Linux

En resumen

Que Linux no inicie no significa automáticamente que el sistema operativo o tus archivos estén perdidos.

Si GRUB desapareció, puede reinstalarse desde un entorno Live utilizando chroot.

Si una actualización del kernel falló, normalmente puede arrancarse utilizando una versión anterior y reconstruir initramfs.

Si el sistema cae en BusyBox, conviene revisar primero el dispositivo raíz, UUID y sistema de archivos.

Si entra en modo de emergencia, journalctl y /etc/fstab suelen proporcionar pistas importantes.

Y si ninguna de estas soluciones funciona, un USB Live normalmente permite al menos montar las particiones y recuperar los archivos antes de plantear una reinstalación.

Conclusión editorial

Uno de los grandes beneficios de Linux es que un sistema aparentemente “muerto” suele continuar siendo completamente accesible desde fuera.

El escritorio puede no aparecer.

GRUB puede estar roto.

El kernel puede no arrancar.

Pero debajo de esas capas continúa existiendo un filesystem con nuestros archivos y una instalación que, en muchos casos, solo necesita que restauremos correctamente la cadena de arranque.

Por eso el primer objetivo nunca debería ser formatear.

Debería ser entender en qué punto se detiene el arranque.

Si el firmware ve el disco, tenemos un comienzo.

Si el Live USB puede montar Linux, tenemos todavía más posibilidades.

Si encontramos /home, podemos salvar nuestros datos.

Si encontramos el kernel y el filesystem está sano, probablemente podamos recuperar también el sistema.

Y cuando aprendemos a utilizar herramientas como lsblk, blkid, chroot, fsck, update-initramfs, mkinitcpio, dracut y GRUB, una pantalla negra deja de significar inmediatamente “reinstalar”.

Se convierte en un problema que puede diagnosticarse por capas.

La mejor reparación, sin embargo, comienza antes del fallo: un kernel anterior funcional, un USB Live preparado, snapshots y un backup externo convierten una emergencia de varias horas en una recuperación de pocos minutos.

Fuentes: GNU GRUB Manual, Ubuntu — GRUB 2 Installation and Recovery, ArchWiki — GRUB, ArchWiki — mkinitcpio y documentación de Red Hat sobre recuperación y reinstalación de GRUB.