Añadir parámetros de arranque al GRUB para evitar problemas de hardware

Si tu PC con Linux no termina de llevarse bien con cierto hardware (gráfica, disco, controladora, Secure Boot, arranque dual con Windows, etc.), una de las herramientas más potentes que tienes a mano es el propio gestor de arranque. Aprender a añadir parámetros de arranque al GRUB para solucionar incompatibilidades de hardware te puede ahorrar reinstalaciones, dolores de cabeza y muchas horas de pruebas a ciegas.

En las siguientes líneas vamos a ver, con calma pero al grano, cómo funciona GRUB por dentro, cómo se configura y qué parámetros de arranque puedes tocar tanto en el kernel como en el propio cargador para tratar fallos de disco, problemas con UEFI/Secure Boot, conflictos con drivers, arranque dual con Windows, arranques lentos o bloqueados, o incluso instalaciones complejas como SUSE en hardware de servidor o IBM Z.

Qué es GRUB y qué papel juegan los parámetros de arranque

Antes de ponerse a editar nada conviene tener claro qué hace exactamente GRUB y por qué los parámetros de arranque son tan críticos cuando hay incompatibilidades de hardware. GRUB (GNU GRand Unified Bootloader) es el programa que se instala en el MBR o en la partición EFI y que se encarga de cargar el kernel de Linux (o encadenar otros sistemas) con una serie de opciones.

Cuando enciendes un PC clásico x86, la BIOS o la UEFI hace sus comprobaciones básicas (RAM, fecha, discos, orden de arranque, etc.) y, si todo está en orden, cede el control al primer sector de arranque del disco, el famoso MBR o la entrada de la partición EFI. Ahí es donde vive la primera etapa de GRUB, cuyo único trabajo realista es localizar y cargar el código de la segunda etapa, que es donde aparece el menú que ves en pantalla.

GRUB se organiza en varias fases: Stage 1 (primer gestor, minúsculo), Stage 1.5 (puente con el sistema de archivos) y Stage 2 (el que sabe leer particiones, sistemas de ficheros, mostrar menús, aceptar comandos, etc.). Según cómo esté instalado, puede arrancar Linux de forma directa (cargando el kernel) o usar “carga en cadena” (chainloading) para delegar en otro gestor, como el de Windows.

Los parámetros de arranque son los ajustes que se pasan al kernel y/o al propio GRUB en el momento de cargar el sistema. Sirven, por ejemplo, para desactivar un driver conflictivo, forzar un modo de vídeo compatible, ajustar mitigaciones de CPU, configurar la red en instalaciones remotas o activar el arranque detallado (verbose) para cazar errores.

Cómo identifica GRUB discos, particiones y archivos

Uno de los puntos que más confunde al principio es la forma en la que GRUB nombra discos y particiones, porque no coincide exactamente con los /dev/sda, /dev/nvme0n1, etc. que ves en Linux. Para GRUB, el primer disco es (hd0), el segundo (hd1), y así sucesivamente, sin importar si son IDE, SATA, SCSI o USB.

Las particiones se indican como (hd0,0), (hd0,1), etc., empezando siempre en 0. Es decir, lo que en Linux es /dev/sda1, para GRUB sería (hd0,0). Si quieres apuntar a todo el disco sin particiones, se omite la coma y el índice, por ejemplo (hd0). Este detalle es clave cuando instalas el cargador de arranque en el MBR: no es lo mismo grub-install /dev/sda que grub-install /dev/sda1, y confundirlos es un clásico.

En Linux moderno, todos los discos aparecen como /dev/sd* (o nvme, etc.), y las particiones se numeran a partir del 1. En tablas MBR solo se permiten cuatro primarias; para tener más, una de ellas se marca como extendida y se crean particiones lógicas numeradas desde la 5 (/dev/sda5, /dev/sda6…). Además, las tablas GPT eliminan buena parte de estas limitaciones, permitiendo muchos más volúmenes y discos de tamaño enorme.

Para lidiar con discos que cambian de nombre (USB, SATA externos, etc.), udev genera enlaces simbólicos estables en /dev/disk/by-id, by-label, by-uuid, etc. Usar estos identificadores únicos en ficheros como /etc/fstab o en configuraciones avanzadas de GRUB ayuda a que el sistema siga arrancando aunque cambie el orden de los discos (cómo saber y cambiar el UUID de una unidad).

Estructura de la configuración de GRUB 2 en distribuciones modernas

En GRUB 2, que es el que traen la mayoría de distros actuales, la configuración efectiva se guarda en /boot/grub/grub.cfg, pero este archivo se genera automáticamente. No está pensado para editarlo a mano, porque cada vez que ejecutas update-grub o se actualiza el kernel, se vuelve a crear a partir de plantillas.

Las opciones más típicas se controlan desde /etc/default/grub. Ahí se definen, por ejemplo, el tiempo que se muestra el menú, la entrada por defecto o los parámetros que se pasan siempre al kernel a través de la variable GRUB_CMDLINE_LINUX_DEFAULT. Cuando modificas este archivo, hay que regenerar la configuración ejecutando update-grub (o el equivalente de tu distro).

Si necesitas añadir menús personalizados (por ejemplo, una entrada con otros parámetros de arranque específicos para cierto hardware), puedes crear o editar /etc/grub.d/40_custom o usar un fichero /boot/grub/custom.cfg. Los scripts en /etc/grub.d (10_linux, 20_linux_xen, 30_os-prober, etc.) son los que se encargan de detectar kernels, sistemas operativos adicionales, entradas de recuperación, etc.

En sistemas que soportan UEFI, cambiar del modo BIOS heredado al modo nativo UEFI no se limita a tocar paquetes de GRUB: implica replantear la tabla de particiones, crear una partición EFI y, a menudo, redimensionar otras. Es un proceso delicado y fácil de estropear si no se hace con cuidado, especialmente cuando se comparte disco con Windows.

Editar parámetros de arranque desde el menú de GRUB

Una forma rápida de probar parámetros de arranque sin tocar ficheros de configuración es editar temporalmente una entrada desde el propio menú de GRUB. Esto viene de cine cuando el sistema no termina de arrancar por culpa de un driver, un modo gráfico incompatible o algún conflicto con el hardware.

Al mostrar el menú, selecciona la entrada que quieras modificar y pulsa la tecla e. Aparecerá el editor de esa entrada, con las líneas que indican el kernel (linux o linuxefi), la initrd y otros parámetros. Para probar opciones, suele bastar con añadir parámetros al final de la línea que empieza por linux o linuxefi. Una vez hecho, arrancas esa configuración pulsando F10 o la combinación indicada en pantalla.

En máquinas con UEFI y GRUB 2 para EFI, el mecanismo es similar, pero no se admiten las antiguas teclas de función de la pantalla BIOS clásica para cambiar idioma o fuentes desde el menú inicial. Hay que editar la entrada con la tecla E y añadir los parámetros a la línea linuxefi. Algunos instaladores, como el de SUSE, funcionan precisamente así cuando quieres definir opciones avanzadas.

Ten presente que estos cambios son temporales: solo afectan al arranque actual. Si compruebas que un parámetro te soluciona el problema de hardware (por ejemplo, una tarjeta gráfica problemática o una controladora que se cuelga), entonces sí, es el momento de llevar la modificación a /etc/default/grub y regenerar el fichero grub.cfg.

Activar el modo verbose y revisar logs para detectar incompatibilidades

Una de las mayores pegas del arranque moderno con splash bonito es que oculta los mensajes del kernel, que es justo lo que necesitas ver cuando algo peta con cierto hardware. Para desactivar el arranque silencioso en distros tipo Ubuntu, edita como root el archivo /etc/default/grub.

Localiza la línea que contiene GRUB_CMDLINE_LINUX_DEFAULT=»quiet splash» y cámbiala por algo como GRUB_CMDLINE_LINUX_DEFAULT=»», o bien deja solo algún parámetro que necesites. Después, ejecuta update-grub para que el cambio entre en vigor. En el siguiente arranque, verás todos los mensajes del kernel y podrás detectar bloqueos, módulos que fallan o servicios que no se inician.

Si el sistema no llega ni siquiera a arrancar, puedes tirar de un Live CD/USB de cualquier distro compatible, montar el sistema de archivos del disco y revisar los registros. Los ficheros clave suelen estar en /var/log/boot.log (mensajes del arranque), /var/log/messages (eventos generales del sistema), dmesg (información del kernel recién cargado) y las salidas de journalctl (si usas systemd).

Analizar estos logs te dará pistas claras de qué módulo de hardware se está colgando, si hay problemas con el disco, con la memoria o con algún servicio esencial. A veces basta con desactivar temporalmente un módulo desde GRUB mediante un parámetro (por ejemplo, blacklist=nombre_modulo o opciones similares) para comprobar si el conflicto se debe a ese driver.

Problemas frecuentes de arranque y relación con hardware

En la práctica, los fallos de arranque en Linux suelen tener unos cuantos sospechosos habituales: particiones dañadas, kernels incompatibles, drivers conflictivos, cambios en el gestor de arranque por culpa de Windows, mala configuración de la BIOS/UEFI o funciones como Secure Boot y Fast Boot.

Un clásico es instalar Windows después de Linux: el instalador de Microsoft pisa el MBR o la entrada EFI y no se molesta en preservar GRUB. El resultado es que solo arranca Windows. La solución pasa por iniciar con una distro Live, montar el sistema y reinstalar GRUB con los comandos adecuados (grub-install y grub-mkconfig / update-grub), a menudo usando chroot. Cuando hay sistemas de ficheros btrfs con subvolúmenes, como en Fedora, hay que tener cuidado de indicar correctamente el subvolumen raíz, o grub2-mkconfig no encontrará la raíz /.

Otro motivo recurrente es una actualización de kernel fallida o un nuevo kernel que no se lleva bien con cierto hardware. En ese caso, lo más práctico es utilizar el menú de GRUB para arrancar un kernel anterior desde las “Advanced options” y comprobar si el problema desaparece. Si es así, puedes quedarte en esa versión mientras investigas o pruebas un kernel más nuevo (o incluso compilar e instalar el kernel para probar parches).

También hay muchos apagones de arranque provocados por drivers privativos (sobre todo de GPU) instalados a mano. Un módulo mal compilado o no compatible con la versión actual del kernel puede provocar cortes en negro, cuelgues o kernel panic. Aquí los parámetros de arranque permiten forzar un modo gráfico seguro, desactivar ciertas funciones avanzadas o incluso arrancar sin cargar el driver conflictivo.

Usar el modo recuperación y comandos internos de GRUB

Si GRUB aparece pero el problema es que Linux no termina de cargar, las entradas de “Advanced options” suelen incluir un modo Recovery para cada kernel. Esta opción arranca con un conjunto más conservador de servicios y te presenta un menú con utilidades de reparación.

Las funciones más prácticas son fsck (revisa y corrige errores del sistema de archivos), clean (libera espacio innecesario), dpkg (repara paquetes rotos en distros Debian/Ubuntu) y la opción para actualizar GRUB desde el propio sistema. Ejecutar estas tareas puede resolver bastantes problemas de arranque ligados, por ejemplo, a cortes de luz durante una actualización.

Desde la línea de comandos de GRUB, accesible con la tecla c, también tienes algunos comandos muy útiles para diagnóstico avanzado: root (indica el sistema de archivos raíz de GRUB), kernel (especifica qué imagen de kernel cargar), initrd (define el disco RAM inicial), chainloader (cargar otro gestor, típico para Windows) o incluso install (para instalar GRUB en el MBR desde el propio entorno de GRUB).

Hay que tener en cuenta que el comando install sobrescribe el MBR, así que solo deberías usarlo cuando tengas claro qué disco es cuál y qué quieres conseguir. Mal ejecutado, puedes quedarte con un sistema totalmente inarrancable hasta que vuelvas a usar un LiveUSB y reconfigures todo.

Reparar GRUB con herramientas externas y Live USB

Cuando el daño en el gestor de arranque es serio o no te apetece pelearte con chroot y comandos a mano, existen herramientas como Boot-Repair en el ecosistema Ubuntu que automatizan buena parte del trabajo. Se ejecutan desde un Live USB, analizan el sistema y reinstalan GRUB, detectan sistemas operativos y reconstruyen el menú.

En el caso de Boot-Repair, se puede instalar desde un Live Ubuntu añadiendo su PPA e instalando el paquete correspondiente. Luego basta con lanzar la aplicación, dejar que analice el sistema y elegir la “reparación recomendada”. Esta opción reinstalará GRUB en el disco correcto, regenerará el menú y, en muchos casos, devolverá la entrada de Windows si había un arranque dual.

Otras distros tienen asistentes similares integrados en sus medios de instalación o en sus herramientas de recuperación. La idea siempre es la misma: arrancar desde otro entorno, montarlo todo, reanclar GRUB en el MBR o en la partición EFI y actualizar la configuración para que se incluyan todos los sistemas presentes.

Comprobar primero que no sea un problema físico

Antes de volverte loco con parámetros de arranque y configuraciones avanzadas, conviene descartar que el problema sea puramente de hardware. La BIOS/UEFI debe detectar el disco o SSD donde está instalado el sistema; si ni siquiera aparece, ningún parámetro de GRUB te va a salvar.

Entra en la configuración de la placa base (teclas típicas: Supr, Esc, F2, F10…) y revisa la sección de Boot / Arranque. Verifica que el disco está presente y que el orden de arranque es el adecuado. Si el disco no se detecta, sospecha de cables SATA flojos, adaptadores defectuosos o una unidad que simplemente ha muerto.

Si llegas al menú de GRUB, puedes lanzar herramientas como MemTest86+ para comprobar el estado de la RAM. Deja correr al menos ocho pasadas; si salen líneas rojas, es que la memoria tiene errores y, tarde o temprano, eso se traducirá en arranques inestables, corrupción de datos y kernel panic.

Para comprobar el estado de los discos, un Live Linux con smartmontools es una opción muy recomendable. A través de smartctl puedes revisar indicadores como Reallocated_Sector_Ct (sectores reasignados), Current_Pending_Sector_Ct (sectores pendientes) o Power_On_Hours (horas de uso). Valores no nulos en los dos primeros son una señal bastante seria de que el disco está cerca del final de su vida útil.

Interacción de GRUB con BIOS, UEFI, Secure Boot y Fast Boot

El contexto de firmware influye muchísimo en cómo se comporta el arranque. En equipos modernos con UEFI, la presencia de y funciones como Fast Boot pueden generar incompatibilidades serias con algunas distros de Linux o con ciertas combinaciones de kernels y módulos.

Secure Boot solo permite arrancar código que esté debidamente firmado, y aunque la mayoría de distribuciones modernas (Ubuntu, Fedora, openSUSE, etc.) ya se han adaptado, hay distros alternativas o muy ligeras que no incluyen firmas válidas. En esos casos, para instalar y arrancar Linux toca desactivar Secure Boot o cambiar al modo Legacy/CSM en la UEFI.

Si compartes equipo con Windows, además, Fast Boot puede causar estragos: al apagar, el sistema no se cierra del todo, sino que hiberna parcialmente el kernel y bloquea el sistema de ficheros NTFS. Esto provoca errores al intentar montarlo desde Linux, y puede impedir un arranque correcto. La solución pasa por desactivar Fast Boot tanto en Windows (opciones de energía) como en la propia UEFI.

Cuando se dan problemas de compatibilidad con Secure Boot, hay casos en los que basta con ajustar parámetros de arranque (por ejemplo, mitigations o modos de vídeo) para que todo funcione. En otros, directamente no hay forma segura de cargar módulos no firmados, y no queda otra que desactivar la función o usar una distro que tenga soporte oficial para Arranque seguro.

Parámetros de arranque típicos en instalaciones SUSE y entornos de servidor

En distribuciones orientadas a servidor como SUSE Linux Enterprise Server, el uso de parámetros de arranque durante la instalación es todavía más habitual, porque permiten configurar red, origen de instalación, acceso remoto, proxies, SELinux o mitigaciones de CPU de forma muy granular.

En arquitecturas AMD64/Intel 64 (y Arm AArch64), la pantalla de arranque de SUSE permite añadir parámetros al kernel para, por ejemplo, forzar la configuración de red con netsetup o ifcfg, indicando IP, máscara CIDR, gateway, DNS y dominio de búsqueda. Esto resulta imprescindible cuando la instalación depende de repositorios HTTP, NFS o Samba remotos.

También se pueden especificar orígenes de instalación alternativos (http, https, nfs, cifs, slp, cd, hd…) e incluso desactivar la verificación de certificados SSL con parámetros como sslcerts=0 cuando se trabaja en entornos de prueba o con infraestructuras que usan certificados propios.

Para instalaciones remotas, SUSE permite activar VNC o SSH directamente desde los parámetros de arranque, usando opciones como vnc=1, vncpassword=CONTRASEÑA o ssh=1 con ssh.password=PASSWORD. Esto abre la puerta a instalar y diagnosticar sistemas a distancia, algo muy útil cuando surgen incompatibilidades de hardware en centros de datos y no puedes plantarte delante de la pantalla.

Otro grupo de parámetros de arranque muy frecuentes en entornos empresariales son los relacionados con conectividad avanzada y seguridad. Si tu red se basa en IPv6, debes habilitarlo explícitamente durante el arranque del instalador para poder configurar direcciones y rutas en ese protocolo.

Cuando el acceso a Internet pasa por un servidor proxy obligatorio, también se puede definir desde el propio arranque mediante un parámetro proxy con la URL del servidor, incluyendo, si hace falta, credenciales de usuario y contraseña. Sin eso, los procesos de registro o descarga de paquetes durante la instalación pueden fallar sin que sea culpa del hardware.

En materia de seguridad, SUSE permite activar SELinux desde el arranque del instalador para que, una vez concluida la instalación, se pueda configurar sin tener que reiniciar el equipo. De forma similar, el parámetro self_update indica si YaST puede auto-actualizarse con parches del propio fabricante durante el proceso de instalación, lo cual es clave cuando se corrigen bugs recientes que afectan a determinados controladores o plataformas.

En cuanto al rendimiento y la seguridad del procesador, el parámetro mitigations controla qué contramedidas contra vulnerabilidades de canal lateral (tipo Spectre, Meltdown, etc.) se aplican. Valores como auto, nosmt u off permiten equilibrar seguridad y rendimiento: por ejemplo, nosmt desactiva el multihilo simultáneo para minimizar riesgos, a costa de perder rendimiento en cargas muy paralelas.

Parámetros específicos para redes avanzadas e IBM Z

En plataformas IBM Z y mainframe, el arranque (IPL) es un mundo aparte. No hay una pantalla de GRUB como tal, sino que el kernel, el initrd y el archivo parmfile se cargan manualmente, y los parámetros de arranque se escriben en ese parmfile en lugar de en un indicador gráfico.

En estos entornos, las interfaces de red pueden ser tipo ctc, escon, iucv, osa (con modos lcs o qdio), hsi (HiperSockets), etc., y cada una requiere parámetros específicos: canales de lectura y escritura (ReadChannel, WriteChannel, DataChannel), tipo de interfaz (qdio o lcs), Layer2=0/1 para activar la capa 2, PortNo para el número de puerto o incluso OSAHWAddr para definir una dirección MAC concreta.

Todos estos ajustes se pasan como parámetros de arranque del kernel y son imprescindibles para que el sistema pueda levantar la red desde el inicio. En un servidor que monta almacenamiento iSCSI, accede a repositorios remotos o necesita conectividad de gestión desde el minuto uno, una mala combinación de parámetros puede parecer un problema de “hardware incompatible” cuando en realidad es puro desajuste de configuración.

Aunque estos escenarios son más comunes en empresas que en escritorios domésticos, merece la pena conocerlos porque ilustran hasta qué punto los parámetros de arranque de GRUB y del kernel pueden determinar la relación con el hardware, incluso en arquitecturas muy distintas al PC estándar.

Reparar particiones y sistemas de archivos antes de tocar GRUB

En muchas ocasiones, lo que bloquea el arranque no es el cargador en sí, sino una partición o un sistema de ficheros dañado. Antes de lanzarse a reconstruir GRUB, tiene sentido verificar si la partición raíz o la de arranque están en buen estado usando herramientas de bajo nivel como fdisk y fsck.

Desde un Live CD/USB, abre un terminal y ejecuta fdisk -l para listar todas las particiones. Así podrás identificar dónde está instalada tu distro (por ejemplo, /dev/sda1 o /dev/sda2). Una vez localizada, puedes lanzar un fsck sobre esa partición con un comando del estilo sudo fsck /dev/sda1 para que revise y repare inconsistencias.

Hay que ser extremadamente prudente: tanto fdisk como fsck modifican la estructura de particiones y el sistema de archivos, y un error puede tirar tus datos por la borda. Es imprescindible contar con una copia de seguridad previa, sobre todo en servidores o en equipos donde tienes información crítica.

Reparar el sistema de ficheros antes de reinstalar GRUB suele evitar que, tras reconstruir el gestor de arranque, vuelvas a toparte con bloqueos porque el kernel no puede montar correctamente la raíz o la partición /boot.

Arranque dual, máquinas virtuales y reinstalaciones sin perder datos

Cuando usas arranque dual con Windows y Linux, las posibilidades de conflictos aumentan. Windows puede reconfigurar el MBR o la partición EFI y desplazar el cargador de Linux. Aquí, además de reinstalar GRUB, conviene revisar parámetros como los relacionados con Fast Boot, Secure Boot y el montaje de particiones NTFS para que no haya sorpresas.

En el mundo de la virtualización (VirtualBox, VMware, etc.), el problema más habitual no tiene tanto que ver con GRUB como con borrados accidentales de directorios de máquinas virtuales. Si eliminas la carpeta donde se guarda el disco virtual de tu Linux, da igual los parámetros de arranque que uses: esa máquina está perdida y solo podrás recuperarla si aún está en la papelera o tienes copias de seguridad.

De cara a reinstalar Linux tras múltiples experimentos con kernels, drivers y parámetros de arranque, es muy buena práctica separar en el disco una partición de datos independiente de la del sistema. Así, si llegas a un punto sin retorno, puedes formatear únicamente las particiones de sistema y arranque y dejar intacta la de /home o de datos, minimizando el impacto.

Algunas distros, como Ubuntu, incluyen incluso una opción de “reinstalar manteniendo archivos personales”, que reinstala el sistema operativo, regenera GRUB y respeta tus documentos. Aun así, conviene no fiarse al cien por cien y seguir haciendo copias de seguridad periódicas, ya que un fallo de disco físico no distingue entre particiones.

Con todo lo anterior sobre la mesa, queda bastante claro que los parámetros de arranque de GRUB y del kernel son una pieza central para lidiar con incompatibilidades de hardware: permiten ajustar cómo se inicializa la red, qué módulos se cargan o se desactivan, de qué forma se tratan las vulnerabilidades de CPU, cómo interactúa el sistema con BIOS/UEFI, Secure Boot o Fast Boot, e incluso cómo se conduce una instalación remota en servidores complejos; dominarlos, combinados con un buen diagnóstico de logs, comprobaciones de hardware y herramientas de reparación de sistemas de archivos, es la mejor manera de recuperar un Linux que no arranca y, sobre todo, de dejar el equipo bien afinado para que los próximos cambios de kernel, drivers o discos no vuelvan a pillarte por sorpresa.