Cuando administras servidores Linux, romper el GRUB es uno de esos problemas que aparecen sin avisar y dejan tu sistema sin arrancar. Aquí aprendes qué es el archivo de configuración del GRUB, cómo se daña y por qué necesitas saber simularlo antes de repararlo.

¿Qué es el archivo grub.cfg y dónde se ubica?

El GRUB es el bootloader que decide cómo arranca tu sistema Linux y qué dispositivos inicia. Toda su configuración vive en un archivo específico que el sistema lee cada vez que enciendes la máquina.

La ruta exacta es /boot/grub/grub.cfg. Dentro encuentras las entradas de arranque, las opciones del kernel y las directrices que indican al sistema cómo cargar el sistema operativo. Puedes inspeccionarlo con less /boot/grub/grub.cfg para verlo con paginación clara [01:30].

¿Puedo editar grub.cfg manualmente? No. El propio archivo lo advierte en sus primeras líneas. El GRUB tiene comandos y utilidades dedicadas para regenerar esta configuración, y modificarlo a mano suele terminar en un sistema que no arranca.

¿Por qué se rompe el GRUB en servidores Linux?

Las causas más frecuentes vienen de operaciones rutinarias que salen mal. No necesitas hacer algo extraño para romperlo.

• Actualizar a una nueva versión del kernel y que la entrada quede mal escrita.
• Ejecutar un comando de GRUB sin saber exactamente qué hace.
• Hacer una instalación que sobrescribe o corrompe el archivo de arranque.
• Que el sistema se dañe durante el proceso de boot por un corte inesperado.

Cualquiera de estos escenarios deja el archivo grub.cfg inservible o ausente, y el resultado siempre es el mismo: el bootloader no encuentra qué cargar.

¿Cómo simular un GRUB roto para practicar la reparación?

Para aprender a reparar primero necesitas romper. La forma más limpia y reversible de hacerlo es renombrar el archivo de configuración para que el sistema no lo encuentre al arrancar.

El comando que uses dentro de tu sesión SSH es:

bash sudo mv /boot/grub/grub.cfg /boot/grub/grub.cfg.bk

La extensión .bk viene de backup y es una nomenclatura estándar cuando mueves o respaldas archivos de configuración [03:45]. Puedes confirmar el cambio con ls /boot/grub/ y verás que grub.cfg ya no existe, solo queda la versión renombrada.

¿Por qué renombrar en lugar de borrar? Porque conservas el archivo original como respaldo. Si algo sale mal durante el ejercicio, puedes revertir el cambio con otro mv y recuperar tu sistema sin reinstalar nada.

Qué pasa cuando reinicias sin grub.cfg

Al ejecutar sudo reboot, la sesión SSH se cierra y el servidor intenta arrancar. Sin el archivo de configuración, el bootloader muestra un error claro: la versión mínima para correr GRUB no se encuentra y aparece el mensaje fatal: int 18: boot failure [05:20].

En ese punto entras a una interfaz limitada del GRUB que no es una CLI tradicional. Comandos como ls existen, pero no se comportan como en bash. El GRUB tiene sus propias directrices e instrucciones, y aunque puedes intentar arrancar manualmente con tab para listar dispositivos, el proceso es complicado y poco práctico.

¿Por qué dominar la reparación del GRUB es clave para un sysadmin?

Un GRUB roto bloquea el acceso al modo recovery, que es justo la herramienta que usarías para arreglar otros problemas del servidor. Te quedas sin la puerta de entrada habitual a las reparaciones.

Para un administrador de servidores Linux, esto puede ser una de las situaciones más complicadas: el sistema está vivo en disco, los datos siguen ahí, pero no hay forma de iniciarlo de manera convencional. La salida pasa por una imagen live de Ubuntu que te permite montar el disco, acceder al sistema afectado y regenerar la configuración del bootloader desde fuera.

Si alguna vez has tocado un servidor de producción, sabes que este escenario no es teórico. Tarde o temprano aparece, y tener el procedimiento claro marca la diferencia entre cinco minutos de reparación y horas de downtime.

¿Has tenido alguna vez un GRUB roto en producción? Cuéntame en los comentarios cómo lo resolviste.