Ubuntu 24.04 se inicia en pantalla negra o en un bucle de arranque: 6 soluciones que suelen resolverlo

diciembre 9, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 8

¿Te fue útil?

Reinicias después de una actualización y la máquina te devuelve la confianza con una pantalla negra. Quizá el logo del fabricante parpadea, quizá ves un cursor que titila, quizá “se reinicia” para siempre como si estuviera practicando para un maratón. En un portátil es molesto. En una máquina remota es un evento que limita tu carrera.

Esto no es un problema de sensaciones. Normalmente es uno de unos pocos modos de fallo muy específicos: inicialización gráfica, un emparejamiento malo de kernel/initramfs, Secure Boot que rechaza un módulo, un tropiezo del gestor de pantalla, un percance de almacenamiento/sistema de ficheros, o GRUB confundido sobre qué significa “root” hoy. A continuación hay seis soluciones que resuelven la gran mayoría de los casos de pantalla negra/bucle de arranque en Ubuntu 24.04 —y un plan rápido para averiguar cuál te está afectando realmente.

Guion rápido de diagnóstico (revisa esto primero)

Cuando estás frente a una pantalla negra, tu trabajo es identificar en qué etapa del arranque falló. No apliques soluciones al azar. Crearás un segundo incidente encima del primero.

Paso 1: ¿Arrancó el kernel siquiera?

Signos de que no: bucle de reinicio instantáneo, sin actividad de disco tras el splash del firmware, ningún menú GRUB, no puedes acceder a TTY, nada en journal del último arranque.
Posibles culpables: problemas de GRUB/EFI, UUID de root incorrecto, initramfs roto, partición del sistema EFI corrupta, cambio en el orden de arranque del firmware.
Moverse a: Solución 6 (GRUB/cargador de arranque) y Solución 3 (initramfs/conjunto de kernels).

Paso 2: El kernel arranca, pero nunca obtienes un inicio de sesión (GUI)

Signos: puedes cambiar a un TTY (Ctrl+Alt+F3), ping funciona, SSH funciona, pero la pantalla está en negro o vuelve al inicio repetidamente.
Posibles culpables: desajuste del controlador GPU, problemas con GDM/Wayland, Secure Boot bloqueando un módulo, sesión Xorg/Wayland rota.
Moverse a: Solución 2 (GPU/nomodeset) y Solución 4 (Secure Boot/MOK), luego Solución 1 (registros).

Paso 3: Arranca “a veces” o sólo tras ciclos de apagado forzoso

Signos: cuelgue intermitente, prompts de fsck, arranque lento, “Started GNOME Display Manager” nunca aparece, o congelaciones aleatorias al detectar almacenamiento.
Posibles culpables: errores de sistema de ficheros, disco en fallo, timeouts NVMe, sistema raíz lleno, configuración de reanudación tras hibernación defectuosa.
Moverse a: Solución 5 (almacenamiento/sistema de ficheros) y las tareas en Tareas prácticas para salud del disco y espacio.

Una regla operativa: si SSH está disponible, haz todo por SSH y mantén una shell root abierta. Es menos glamuroso que pelear con una consola local, pero así evitas empeorar las cosas.

Datos interesantes y contexto (por qué ocurre)

Ubuntu 24.04 es una LTS (Soporte a Largo Plazo), lo que significa que es conservador en algunos aspectos—pero aún usa kernels y pilas gráficas más recientes que LTS puntuales anteriores.
“Pantalla negra” suele ser una falla de la tubería de display, no del sistema. Muchas máquinas están completamente iniciadas con red activada; la pantalla simplemente te engaña.
Wayland se convirtió en predeterminado en muchas instalaciones de escritorio de Ubuntu hace años, y cambió dónde aparecen las fallas (compositor vs. Xorg) y cómo depurarlas.
El controlador propietario de NVIDIA sigue siendo la causa principal de “arrancar a pantalla negra” tras actualizaciones en escritorios. No porque sea malvado—sino porque se integra profundamente con el kernel/GL y es sensible a cambios de ABI.
Secure Boot no “rompe Linux”, pero puede impedir la carga de módulos de kernel no firmados, lo que se ve exactamente como “el controlador desapareció”.
initramfs es un pequeño sistema de ficheros de arranque temprano creado a partir de los controladores y scripts del sistema; si falta controladores de almacenamiento o hay rutas de módulos obsoletas, el kernel arranca y luego no puede montar root.
El trabajo de GRUB se complicó con UEFI, porque ya no sólo cargas un cargador desde un MBR: navegas entradas de firmware, archivos EFI y peculiaridades del proveedor.
Los bucles de arranque suelen ser systemd reiniciando por fallo, que es genial para demonios y terrible para humanos sin registros.
Un root lleno a menudo se presenta como un problema gráfico porque el gestor de pantalla no puede escribir estado, registros o tokens de autenticación, por lo que se bloquea o entra en bucle.

Una idea (parafraseada) de Werner Vogels, ex CTO de AWS, que aplica aquí: “Todo falla, todo el tiempo; diseña y opera suponiendo eso”. Trata una pantalla negra como un modo de fallo normal con un guion, no como un insulto personal.

Broma #1: Una pantalla negra es la manera en que tu ordenador pide menos sorpresas y más registro. No está equivocado.

Las 6 soluciones que suelen resolverlo

Solución 1: Consigue una consola y lee los registros de arranque con intención

Antes de “arreglar” nada, necesitas evidencia. Tus objetivos:

Buffer del anillo del kernel (errores de controladores, fallos GPU, timeouts de almacenamiento)
journal de systemd (bucles de fallos de servicios, fallos del gestor de pantalla)
Registros del arranque anterior (si el sistema se reinició a mitad del arranque)

Si la máquina es local, prueba cambiar a un TTY: Ctrl+Alt+F3. Si es remota, prueba SSH. Si ninguno funciona, estás en territorio de cargador de arranque/initramfs—salta a Solución 3 y Solución 6.

Lo que buscas no es “un error” aislado sino un patrón: reinicios repetidos de la GPU, “Failed to start GDM”, fallos “drm”, “EXT4-fs error”, “nvme timeout”, o rechazo de módulo por Secure Boot.

Solución 2: Reinicio del GPU/controlador (NVIDIA, AMD, Intel) y la triage con “nomodeset”

Los problemas gráficos tienden a dividirse en dos categorías:

La ruta de kernel modesetting está rota (te cuelgas temprano, pantalla negra, quizá un cursor que parpadea).
La ruta del gestor de pantalla/compositor está rota (el kernel arranca, pero la GUI no inicia o entra en bucle).

Movimiento de triage: usa nomodeset temporalmente para conseguir un arranque y recopilar registros. Esto no es la “solución”. Es la palanca que abre la tapa.

Si es NVIDIA, la “solución” suele ser: llegar a un TTY, purgar el controlador roto, arrancar temporalmente con el controlador abierto o nouveau, y luego reinstalar un paquete NVIDIA conocido y compatible con tu kernel. Si es AMD/Intel, es más común una regresión de kernel o un initramfs obsoleto que le falta firmware.

Wayland vs Xorg también importa. GDM puede configurarse para usar Xorg cuando Wayland falla con ciertos controladores. No trates eso como derrota; trátalo como una estrategia de contención.

Solución 3: Reconstruir initramfs y verificar el conjunto de kernels

Cuando Ubuntu actualiza kernels, también crea nuevas imágenes initramfs. Si la creación de initramfs falla (disco lleno, actualización interrumpida, fallo en script postinst), puedes acabar con:

GRUB que apunta a un kernel que existe pero a un initramfs que no
initramfs presente pero con módulos/firmware faltantes por errores de compilación
un kernel que arranca pero no puede montar root, provocando bucles de arranque

Tu movimiento: arranca con un kernel más antiguo desde GRUB si está disponible, luego reconstruye initramfs para todos los kernels instalados. Si ningún kernel antiguo funciona, usa modo recuperación o un live ISO + chroot.

Esta solución es también donde limpias un conjunto de paquetes de kernel medio instalados. Un módulo DKMS roto (común con NVIDIA o VirtualBox) también puede abortar la generación de initramfs.

Solución 4: Secure Boot, inscripción MOK y por qué tu módulo “desapareció”

Secure Boot es genial cuando quieres saber qué código pudo ejecutarse en el arranque. Es menos genial cuando olvidas que lo activaste y luego instalas controladores de terceros que requieren módulos de kernel.

Síntoma típico: después de una actualización, arrancas y ves pantalla negra o la GUI falla, y los registros muestran fallos de carga de módulos. Para NVIDIA lo verás en journalctl y dmesg. Para otros módulos DKMS, puedes ver una compilación DKMS que tiene éxito pero los módulos no se cargan por problemas de firma.

La solución es o bien:

inscribir correctamente la Machine Owner Key (MOK) y firmar los módulos, o
desactivar temporalmente Secure Boot en el firmware para confirmar causalidad (y luego decidir tu política).

Si gestionas endpoints en producción, “desactivar Secure Boot para siempre” rara vez es una norma aceptable. Úsalo como palanca diagnóstica, no como un estilo de vida permanente.

Solución 5: Reparar problemas de sistema de ficheros/almacenamiento que se hacen pasar por “gráficos”

Aquí hay un secreto sucio: muchos reportes de “pantalla negra” son en realidad fallos de almacenamiento. El sistema arranca hasta que se encuentra con:

un sistema de ficheros corrupto que activa el modo de emergencia
un sistema raíz 100% lleno, haciendo que los servicios fallen de maneras sorprendentes
un dispositivo NVMe lanzando timeouts, bloqueando udev y systemd

Y dado que el gestor de pantalla aparece hacia el final de la cadena de arranque, recibe la culpa. Es como gritar al camarero porque la cocina se quedó sin gas.

Arreglar esto implica comprobar la salud del disco, confirmar que puedes montar root en lectura/escritura, ejecutar fsck cuando proceda, y garantizar espacio libre suficiente para journal, actualizaciones y cachés de shaders GPU.

Solución 6: Reparaciones de GRUB y cargador de arranque (UEFI, partición EFI y root equivocado)

Si nunca llegas de forma fiable al kernel, estás en tierra del cargador de arranque. Ubuntu 24.04 en hardware moderno casi siempre arranca por UEFI desde una EFI System Partition (ESP). Fallos comunes:

ESP llena o corrupta
Entrada de firmware que apunta a un archivo EFI inexistente
configuración de GRUB que apunta al UUID de root equivocado tras clonar disco o reparticionar
cambios por dual-boot cuando Windows altera el orden de arranque

La solución es confirmar que la ESP está montada, reinstalar GRUB para UEFI, regenerar grub.cfg, y validar los UUID en /etc/fstab y la visión de discos de GRUB.

Broma #2: El firmware UEFI tiene personalidad, y es del tipo que “olvida” tu entrada de arranque justo antes de una fecha límite.

Tareas prácticas: comandos, qué significa la salida, qué decides

A continuación hay tareas reales que ejecuto en modo incidente. Cada una incluye: el comando, salida de ejemplo, qué significa, y la decisión que tomas.

Task 1: Confirmar si puedes alcanzar un TTY y qué kernel tienes

cr0x@server:~$ uname -a
Linux server 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 10 12:34:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Qué significa: El kernel está funcionando. Esto no es un problema de “no poder arrancar”; es un problema de “no conseguir una sesión usable” (GUI, controladores, servicios o retrasos de almacenamiento).

Decisión: Centrarte en los registros (Task 2/3) y en display/GPU (Task 6–10), no en cirugía de GRUB todavía.

Task 2: Inspeccionar errores críticos del arranque anterior

cr0x@server:~$ journalctl -b -1 -p err --no-pager | tail -n 30
Sep 22 08:11:02 server kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel
Sep 22 08:11:03 server gdm3[1223]: Failed to start session: Failed to open display
Sep 22 08:11:03 server systemd[1]: gdm.service: Main process exited, code=exited, status=1/FAILURE
Sep 22 08:11:03 server systemd[1]: gdm.service: Failed with result 'exit-code'.

Qué significa: Están implicados firma de módulos o verificación de Secure Boot, y GDM falla porque la pila GPU no arrancó.

Decisión: Ir a Solución 4 (Secure Boot/MOK) y Solución 2 (recuperación de controladores). No pierdas tiempo reinstalando GNOME.

Task 3: Encontrar la etapa de arranque donde el sistema se estanca

cr0x@server:~$ systemd-analyze blame | head -n 15
1min 12.340s dev-nvme0n1p3.device
  45.122s network-online.target
  18.090s plymouth-quit-wait.service
  12.881s systemd-journald.service
  11.004s snapd.seeded.service

Qué significa: El kernel y systemd están vivos; una unidad de dispositivo (partición NVMe) está tardando más de un minuto. Eso suele ser timeouts, reintentos o un disco inestable.

Decisión: Trátalo como un problema de fiabilidad de almacenamiento (Solución 5). Espera que dmesg muestre timeouts NVMe.

Task 4: Buscar en dmesg resets de GPU, timeouts de almacenamiento o firmware faltante

cr0x@server:~$ dmesg -T | egrep -i "nvidia|amdgpu|i915|drm|nvme|EXT4-fs error|I/O error|firmware" | tail -n 40
[Mon Sep 22 08:12:01 2025] nvme nvme0: I/O 114 QID 7 timeout, aborting
[Mon Sep 22 08:12:08 2025] EXT4-fs (nvme0n1p3): recovery complete
[Mon Sep 22 08:12:10 2025] i915 0000:00:02.0: [drm] GuC firmware load failed

Qué significa: Múltiples señales de alerta: timeouts de almacenamiento, recuperación ext4 y firmware i915 faltante. Cualquiera de estos puede provocar una pantalla negra.

Decisión: Priorizar la salud del almacenamiento y los paquetes de firmware. Si el disco está muriendo, ningún ajuste de pantalla te salvará.

Task 5: Verificar espacio libre (una comprobación aburrida que arregla sorpresas en el arranque)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3    97G   97G     0 100% /

Qué significa: Root está lleno. Servicios que necesitan escribir (gdm, journald, triggers de apt, sesiones de usuario) fallarán de formas extrañas, incluyendo bucles de inicio y pantallas negras.

Decisión: Liberar espacio inmediatamente (registros, kernels antiguos, caches). Luego volver a ejecutar la configuración de paquetes pendiente y reconstruir initramfs si es necesario (Solución 3).

Task 6: Comprobar qué GPU y pila de controladores detecta el sistema

cr0x@server:~$ lspci -nnk | egrep -A3 "VGA|3D|Display"
00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P GT2 [8086:46a6]
	Subsystem: Lenovo Device [17aa:3a21]
	Kernel driver in use: i915
	Kernel modules: i915

Qué significa: i915 de Intel es el controlador activo. La pantalla negra podría deberse a firmware, regresión de kernel o comportamiento del gestor de pantalla/Wayland.

Decisión: Si dmesg muestra fallos de carga de firmware, instala el firmware faltante y reconstruye initramfs (Solución 3). Si es específico de Wayland, prueba fallback a Xorg (Task 10).

Task 7: Comprobar si GDM está fallando o en bucle

cr0x@server:~$ systemctl status gdm --no-pager
● gdm.service - GNOME Display Manager
     Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-09-22 08:11:03 UTC; 2min 12s ago
   Main PID: 1223 (code=exited, status=1/FAILURE)

Sep 22 08:11:03 server gdm3[1223]: GdmDisplay: Session never registered, failing
Sep 22 08:11:03 server systemd[1]: gdm.service: Failed with result 'exit-code'.

Qué significa: El gestor de pantalla no inició una sesión funcional. Esto puede ser el controlador GPU, un problema de Wayland, permisos o síntomas de disco lleno.

Decisión: Extraer logs de GDM (Task 8) y decidir si cambiar a Xorg o usar temporalmente otro gestor de pantalla como contención.

Task 8: Extraer los registros de GDM y GNOME Shell del arranque actual

cr0x@server:~$ journalctl -b -u gdm --no-pager | tail -n 80
Sep 22 08:10:59 server gdm3[1102]: Enabling debugging
Sep 22 08:11:02 server gdm3[1223]: Gdm: GdmDisplay: no session desktop files installed
Sep 22 08:11:03 server gdm3[1223]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

Qué significa: “No session desktop files” sugiere paquetes dañados o una actualización parcialmente completada, no únicamente un problema de GPU.

Decisión: Validar el estado de paquetes (Task 11), luego reinstalar los paquetes de sesión de escritorio si es necesario. No sigas reiniciando esperando que se arregle solo.

Task 9: Arranque temporal con “nomodeset” para obtener una consola/GUI base

cr0x@server:~$ grep -n "GRUB_CMDLINE_LINUX_DEFAULT" /etc/default/grub
6:GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Qué significa: nomodeset está habilitado persistentemente en GRUB. Eso a menudo permite arrancar pero desactiva la aceleración GPU adecuada y puede limitar resoluciones.

Decisión: Usar esto solo como muleta diagnóstica. Una vez arreglado el controlador/firmware real, elimina nomodeset y regenera GRUB (Task 16).

Task 10: Forzar a GDM a usar Xorg en lugar de Wayland (movida común de contención)

cr0x@server:~$ sudo sed -n '1,80p' /etc/gdm3/custom.conf
# GDM configuration storage
[daemon]
# Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false

Qué significa: Wayland está deshabilitado para GDM. Esto suele estabilizar sistemas con ciertas configuraciones NVIDIA o regresiones de composición.

Decisión: Si esto resuelve la pantalla negra, mantenlo como mitigación a corto plazo y planifica una ventana de actualización de controladores/kernel más adelante.

Task 11: Comprobar una actualización rota (paquetes medio configurados, fallos DKMS)

cr0x@server:~$ sudo dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 linux-image-6.8.0-41-generic   Linux kernel image for version 6.8.0 on 64 bit x86 SMP

Qué significa: El paquete de kernel no terminó de configurarse—a menudo debido a fallo en la generación de initramfs, disco lleno o error DKMS.

Decisión: Arreglar prerrequisitos (espacio, errores DKMS), luego ejecutar dpkg --configure -a y reconstruir initramfs (Solución 3).

Task 12: Reconstruir initramfs para todos los kernels

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-40-generic

Qué significa: Se generaron las imágenes initramfs exitosamente. Si viste errores aquí, importan; desplázate arriba y arréglalos en lugar de reiniciar con esperanza.

Decisión: Si la generación tiene éxito, actualiza GRUB y reinicia. Si falla por DKMS, resuelve primero el build/firma del módulo (a menudo Solución 4 para Secure Boot).

Task 13: Identificar kernels instalados y elegir un fallback en GRUB

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2}'
linux-image-6.8.0-40-generic
linux-image-6.8.0-41-generic
linux-image-generic

Qué significa: Tienes al menos dos kernels. Esa es tu red de seguridad.

Decisión: Si 6.8.0-41 falla, arranca 6.8.0-40 desde “Advanced options for Ubuntu” y repara desde ahí (Solución 3 / Solución 2 dependiendo de síntomas).

Task 14: Verificar el estado de Secure Boot desde el sistema en ejecución

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Qué significa: Secure Boot está habilitado, por lo que módulos de terceros no firmados pueden ser bloqueados.

Decisión: Si dependes de NVIDIA u otros módulos DKMS, asegúrate de la inscripción MOK y de la firma correcta de módulos (Solución 4). No sigas reinstalando controladores sin abordar la firma.

Task 15: Comprobar si el módulo kernel NVIDIA está cargado (si procede)

cr0x@server:~$ lsmod | egrep '^nvidia|nouveau'
nouveau              2795520  2

Qué significa: El sistema usa nouveau, no el módulo propietario NVIDIA. Eso puede ser intencional, o puede significar que NVIDIA no pudo cargar.

Decisión: Si necesitas NVIDIA propietario para CUDA/3D, revisa journal por fallos de carga de módulo y problemas de Secure Boot (Solución 4), luego reinstala la versión correcta del controlador (Solución 2).

Task 16: Actualizar la configuración de GRUB tras cambios

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
Found linux image: /boot/vmlinuz-6.8.0-40-generic
Found initrd image: /boot/initrd.img-6.8.0-40-generic
done

Qué significa: GRUB ve ambos kernels e initramfs. Bien.

Decisión: Si GRUB no lista las imágenes esperadas, para e inspecciona la capacidad de /boot y la salud del sistema de ficheros (Solución 5).

Task 17: Comprobar montaje y espacio libre de la EFI System Partition (problemas UEFI)

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE         FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro

Qué significa: La ESP está montada y es escribible (por ahora). Si falta, las instalaciones de GRUB pueden “tener éxito” pero no aterrizar donde el firmware lo espera.

Decisión: Si la ESP no está montada, móntala, revisa /etc/fstab y repara entradas GRUB/EFI (Solución 6).

Task 18: Ejecutar un chequeo de sistema de ficheros cuando el sistema esté en modo de emergencia o desde un entorno live

cr0x@server:~$ sudo fsck -f /dev/nvme0n1p3
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p3: recovering journal
/dev/nvme0n1p3: clean, 512345/6553600 files, 8123456/26214400 blocks

Qué significa: Se recuperó el journal y el sistema de ficheros ahora está limpio.

Decisión: Si fsck informa errores no corregibles o corrupción recurrente, deja de tratar esto como un problema de software. Sustituye el disco y restaura.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana gestionaba una flota de estaciones de trabajo Ubuntu para desarrolladores y unas cuantas máquinas GPU on-prem para entrenamiento de modelos. Un lunes por la mañana, varios escritorios se actualizaron el fin de semana y aparecieron “muertos”: pantalla negra, ventiladores girando, sin GUI.

El ingeniero on-call supuso que era una regresión de GNOME porque “la pantalla de login está negra, así que debe ser el escritorio”. Reinstalaron paquetes de escritorio por shell de rescate, reiniciaron GDM y probaron varios gestores de pantalla. Sin suerte. Mientras tanto, más máquinas se autoactualizaban al mismo estado.

El modo real de fallo: una actualización de BIOS en un lote de portátiles habilitó Secure Boot en el firmware. El módulo del controlador propietario GPU ya no se aceptaba sin la inscripción MOK apropiada. Las máquinas arrancaban bien; la pila gráfica no.

La recuperación llegó cuando alguien hizo lo poco glamuroso: journalctl -b -p err y lo leyó de principio a fin. Los errores de verificación de módulo estaban ahí mismo. Una vez estandarizaron inscribir MOK durante la instalación del controlador o cambiar las máquinas afectadas temporalmente a Xorg, la flota se recuperó rápido.

La lección no fue “Secure Boot malo”. Fue “las suposiciones son caras”. Cuando la pantalla está negra, los registros del kernel son tu realidad.

Mini-historia 2: La optimización que salió mal

Un equipo distinto quería mayor cumplimiento de parches en endpoints de empleados. Ajustaron unattended upgrades para aplicar automáticamente y reiniciar por la noche. En teoría genial: menos vulnerabilidades persistentes, menos reinicios manuales, menos “lo haré después”.

Luego un desajuste driver-kernel afectó a un subconjunto de máquinas con GPU discretas. El reinicio ocurrió silenciosamente a las 3 a.m. A la mañana siguiente, los usuarios encontraron pantallas negras y una cola de helpdesk que parecía un ataque de denegación de servicio—excepto autoinfligido.

La “optimización” asumía que los reinicios son un commodity inocuo. En realidad, los reinicios son cambios en producción: kernel, initramfs, controladores, firmware y cargadores de arranque se ejercitan. Si no tienes despliegues por fases, canarios o al menos una puerta que impida reiniciar si el último arranque fue malo, estás jugando a la ruleta a escala.

Lo arreglaron implementando despliegues por fases (incluso un esquema simple por anillos), manteniendo al menos dos kernels conocidos buenos y asegurando acceso remoto disponible (SSH habilitado, acceso a consola documentado). Las actualizaciones automáticas quedaron, pero con guardarraíles. Aburrido, efectivo.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización financiera ejecutaba Ubuntu en varios cientos de portátiles y algunas estaciones compartidas. Su postura de seguridad era estricta, por lo que Secure Boot permanecía habilitado. También tenían una práctica sencilla pero disciplinada: cada máquina mantenía dos kernels instalados, y rutinariamente validaban que GRUB mostrara “Advanced options” con múltiples entradas.

Cuando una actualización de kernel causó una regresión en un modelo de hardware particular, no necesitaron heroísmos. Los usuarios sabían seleccionar el kernel previo en GRUB. TI tenía un script corto para pinchar la versión de kernel mala y retener actualizaciones hasta que llegara la corrección.

Lo que funcionó no fue brillante técnicamente. Fue la memoria operativa: “Si un kernel nuevo falla, arranca el anterior, recopila registros y luego remedia”. También tenían la costumbre de comprobar espacio libre en / y /boot durante mantenimientos rutinarios, lo que previno el clásico fallo de generación de initramfs por filesystem lleno.

El incidente no se convirtió en crisis porque la organización trató la arrancabilidad como una característica de fiabilidad—probada, preservada y documentada. Previsibilidad vence a la genialidad.

Errores frecuentes: síntoma → causa raíz → solución

1) Síntoma: Pantalla negra, pero puedes entrar por SSH

Causa raíz: Fallo del gestor de pantalla (GDM) debido a desajuste de controlador GPU, problemas de Wayland o disco lleno.
Solución: Comprueba systemctl status gdm y journalctl -u gdm. Si es NVIDIA, valida carga de módulo + Secure Boot (Solución 4). Prueba fallback a Xorg (Solución 2 / Task 10). Revisa uso de disco (Task 5).

2) Síntoma: Bucle de arranque tras actualización de kernel; GRUB aparece brevemente

Causa raíz: initramfs roto o fallo postinst del kernel; a veces DKMS falló durante la actualización.
Solución: Arranca un kernel antiguo, ejecuta dpkg --configure -a, luego update-initramfs -u -k all y update-grub (Solución 3).

3) Síntoma: “Started GNOME Display Manager” nunca aparece; largos estancamientos

Causa raíz: Retrasos de almacenamiento (timeous NVMe), esperas de fsck o disco fallando.
Solución: Usa systemd-analyze blame y dmesg filtrando por nvme/I/O (Task 3/4). Ejecuta fsck según proceda (Task 18). Sustituye hardware sospechoso (Solución 5).

4) Síntoma: Bucle de inicio de sesión (introduces la contraseña y vuelve al login)

Causa raíz: Disco lleno, ficheros de sesión de usuario rotos, permisos wrong en home, o GDM/Wayland crash.
Solución: Comprueba df -h, arregla espacio; inspecciona journalctl por errores de sesión; prueba fallback a Xorg; confirma permisos de home. Reinicia gdm tras la remediación.

5) Síntoma: Pantalla negra inmediatamente después de seleccionar Ubuntu en GRUB

Causa raíz: Regresión de kernel modesetting o deadlock del controlador GPU temprano en el arranque.
Solución: nomodeset temporal en GRUB para arrancar, luego reparar controlador/firmware y quitar nomodeset (Solución 2).

6) Síntoma: No hay menú GRUB; va directo al firmware o “no hay dispositivo de arranque”

Causa raíz: Entrada de arranque EFI ausente, ESP corrupta/no montada, disco no detectado.
Solución: Verifica orden de arranque del firmware, monta la ESP, reinstala GRUB en modo UEFI vía chroot si es necesario (Solución 6). Si falta el disco, es hardware.

Listas de verificación / plan paso a paso

Checklist A: Si puedes acceder a un TTY o SSH (caso más común)

Confirmar que el kernel está en ejecución: uname -a.
Extraer errores del arranque previo: journalctl -b -1 -p err.
Comprobar espacio en disco: df -h / y también df -h /boot, df -h /boot/efi.
Comprobar estado de GDM: systemctl status gdm y journalctl -u gdm.
Comprobar estado del controlador GPU: lspci -nnk, lsmod, y dmesg -T para errores drm/gpu.
Si NVIDIA + Secure Boot habilitado: confirma con mokutil --sb-state y decide la inscripción MOK (Solución 4).
Reparar estado de paquetes: dpkg --audit, luego dpkg --configure -a si procede.
Reconstruir initramfs: update-initramfs -u -k all, luego update-grub.
Contención si es necesario: forzar Xorg en /etc/gdm3/custom.conf y reiniciar gdm.
Reiniciar una vez—un reinicio limpio, no cinco enfadados—luego volver a revisar registros.

Checklist B: Si no puedes acceder a TTY/SSH (camino cargador de arranque/initramfs)

En el arranque, fuerza el menú GRUB (mantén Shift o presiona Esc según el timing del firmware).
Prueba “Advanced options” y arranca un kernel más antiguo.
Prueba el modo recuperación y “root” shell. Si obtienes shell, procede con Checklist A desde la inspección de registros y comprobaciones de disco.
Si ningún kernel instalado arranca: usa un live ISO de Ubuntu, monta root, chroot, luego reconstruye initramfs y reinstala GRUB (Solución 3 + Solución 6).
Verifica el montaje de ESP y reconstruye entradas de arranque EFI.
Sólo después de que la remediación por software falle: sospecha hardware del disco/controlador.

Checklist C: Reglas de “no empeorarlo”

No elimines paquetes al azar hasta haber capturado registros de journalctl -b -1 y dmesg.
No sigas reiniciando; borras evidencia y estresas hardware que falla.
No fijes el sistema a nomodeset permanentemente a menos que sea un quiosco y disfrutes de baja resolución y rarezas.
No desactives Secure Boot permanentemente como reflejo. Decide con intención: política de seguridad vs. simplicidad operativa.

FAQ

1) ¿Cómo sé si es “sólo la GUI” y no todo el sistema?

Si puedes cambiar a un TTY (Ctrl+Alt+F3) o entrar por SSH, el kernel arrancó y systemd está en ejecución. Entonces estás depurando el gestor de pantalla/gráficos o retrasos de almacenamiento de fin de arranque, no GRUB.

2) ¿“nomodeset” arregla el problema?

No. A menudo te permite arrancar evitando kernel modesetting, lo que te da un punto de apoyo para reparar controladores/firmware. Trátalo como una rueda de repuesto.

3) ¿Por qué una actualización del controlador NVIDIA causa pantalla negra tras actualizar el kernel?

La pila propietaria de NVIDIA depende de interfaces del kernel y compila módulos (a menudo vía DKMS). Si la compilación del módulo falla, o Secure Boot lo bloquea, la pila de display no puede iniciarse.

4) ¿Cuál es el comando de logs más rápido que suele decir la verdad?

journalctl -b -1 -p err es un buen inicio, especialmente tras un bucle de arranque. Filtra a errores del arranque previo, cuando ocurrió la falla.

5) ¿Un disco lleno realmente puede causar pantalla negra?

Sí. GDM, GNOME Shell e incluso componentes de autenticación necesitan escribir ficheros. Si / está lleno, puedes tener bucles de inicio de sesión, fallos de sesión y un escritorio “en blanco”.

6) ¿Debería cambiar de Wayland a Xorg?

Si estás bloqueado y necesitas la máquina usable hoy, sí—cambiar GDM a Xorg es una medida de contención razonable. Luego programa tiempo para arreglar el controlador/kernel subyacente.

7) ¿Cómo me recupero si ni siquiera veo el menú GRUB?

Intenta forzarlo con Esc/Shift durante el arranque. Si el firmware nunca cede a GRUB, puede que necesites un live ISO para reparar la entrada de arranque EFI y reinstalar GRUB (Solución 6).

8) ¿Es esto más común en escritorios que en servidores?

Sí. Los servidores a menudo funcionan sin GUI y con necesidades de controladores conservadoras. Los escritorios combinan GPUs, compositores y cambios frecuentes de controladores—más piezas móviles, más modos de fallo.

9) Si fsck “arregla” las cosas una vez, ¿he terminado?

No necesariamente. Una recuperación tras un apagado no limpio es normal. Reparaciones frecuentes de sistema de ficheros o timeouts NVMe recurrentes son una señal de fiabilidad: vigila SMART/salud y planifica reemplazo.

Conclusión: próximos pasos para evitar incidentes repetidos

Las pantallas negras y bucles de arranque en Ubuntu 24.04 rara vez son misteriosas. Normalmente son una de seis cosas: controladores GPU, desajuste initramfs/kernel, política de módulos con Secure Boot, problemas del gestor de pantalla/Wayland, fallos de almacenamiento/sistema de ficheros, o deriva de GRUB/EFI. El truco es identificar rápido la etapa de fallo y aplicar la solución que coincida con la evidencia.

Próximos pasos que realmente reducen el dolor futuro:

Mantén al menos dos kernels instalados y confirma que GRUB los muestra.
Haz comprobaciones de espacio libre rutinarias para /, /boot y /boot/efi.
Si usas NVIDIA y Secure Boot, estandariza la inscripción MOK y los procedimientos de firma de módulos en lugar de improvisar por máquina.
Aplica actualizaciones y reinicios por fases. Un reinicio es un cambio, lo respetes o no.
Cuando algo falla, captura la salida de journalctl -b -1 antes de empezar a “arreglar”. Los registros no mienten; los humanos sí.