Ubuntu 24.04 démarre sur un écran noir ou en boucle : 6 correctifs qui résolvent généralement le problème

Playbook de diagnostic rapide (vérifiez ceci en premier)

Quand vous fixez un écran noir, votre tâche est d’identifier à quel stade du démarrage l’échec s’est produit. Ne lancez pas des correctifs au hasard. Vous allez créer un second incident par‑dessus le premier.

Étape 1 : Le noyau a‑t‑il démarré du tout ?

• Signes qu’il n’a pas démarré : boucle de redémarrage instantanée, aucune activité disque après l’écran du firmware, pas de menu GRUB, impossibilité d’atteindre un TTY, rien dans le journal pour le dernier démarrage.
• Coupables probables : problèmes GRUB/EFI, mauvais UUID de root, initramfs cassé, partition système EFI corrompue, ordre de démarrage modifié par le firmware.
• Aller à : Correctif 6 (GRUB/bootloader) et Correctif 3 (initramfs/ensemble de noyaux).

Étape 2 : Le noyau démarre, mais vous n’obtenez jamais de session graphique

• Signes : vous pouvez basculer vers un TTY (Ctrl+Alt+F3), le ping fonctionne, SSH fonctionne, mais l’affichage est noir ou revient sans cesse à l’écran de connexion.
• Coupables probables : incompatibilité du pilote GPU, problèmes GDM/Wayland, Secure Boot bloquant un module, session Xorg/Wayland cassée.
• Aller à : Correctif 2 (GPU/nomodeset) et Correctif 4 (Secure Boot/MOK), puis Correctif 1 (journaux).

Étape 3 : Ça démarre « parfois » ou seulement après des cycles d’alimentation forcés

• Signes : blocages intermittents, invites fsck, démarrage retardé, « Started GNOME Display Manager » n’apparaît jamais, ou gels aléatoires pendant le sondage du stockage.
• Coupables probables : erreurs de système de fichiers, disque en fin de vie, timeouts NVMe, système de fichiers racine plein, mauvaise configuration de reprise depuis l’hibernation.
• Aller à : Correctif 5 (stockage/systèmes de fichiers) et aux tâches dans Tâches pratiques pour l’état des disques et l’espace disponible.

Règle opérationnelle : si SSH est disponible, faites tout via SSH et gardez un shell root ouvert. C’est moins spectaculaire que de tripoter une console locale, mais c’est comme ça que vous évitez d’empirer les choses.

Faits et contexte intéressants (pourquoi cela arrive)

• Ubuntu 24.04 est une LTS (Long Term Support), ce qui signifie qu’il est conservateur sur certains points — mais il embarque quand même des noyaux et des piles graphiques plus récents que les anciennes versions LTS.
• « Écran noir » est souvent une panne de la chaîne d’affichage, pas une panne système. Beaucoup de machines sont entièrement démarrées avec le réseau actif ; c’est juste l’écran qui vous ment.
• Wayland est devenu le choix par défaut pour de nombreuses installations de bureau Ubuntu, et cela a déplacé l’endroit où les échecs apparaissent (compositeur vs Xorg) et la façon de les déboguer.
• Le pilote propriétaire NVIDIA reste la première cause des « démarrages vers un écran noir » après mise à jour sur les postes de travail. Pas parce qu’il est malfaisant — parce qu’il s’accroche profondément aux interfaces noyau/GL et est sensible aux changements d’ABI.
• Secure Boot n’« casse » pas Linux, mais il peut empêcher le chargement de modules noyau non signés, ce qui ressemble exactement à « le pilote a disparu ».
• Initramfs est un minuscule système de fichiers du tout début du démarrage créé à partir des pilotes et scripts de votre système ; s’il manque des pilotes de stockage ou s’il contient des chemins de modules obsolètes, le noyau peut démarrer puis ne pas monter root.
• Le travail de GRUB s’est compliqué avec l’UEFI, car vous ne chargez plus seulement un bootloader depuis un MBR — vous naviguez dans des entrées de firmware, des fichiers EFI et des particularités constructeurs.
• Les boucles de démarrage sont souvent le « restart on failure » de systemd qui fait son travail, ce qui est parfait pour les démons et horrible pour les humains sans journaux.
• Un système de fichiers racine plein se présente souvent comme un problème graphique parce que le gestionnaire d’affichage ne peut pas écrire d’état, de journaux ou de jetons d’authentification, il plante ou boucle.

Une idée (paraphrasée) de Werner Vogels, ancien CTO d’AWS, qui s’applique ici : « Tout casse, tout le temps ; concevez et exploitez en partant de ce principe. » Traitez un écran noir comme un mode normal d’échec avec un playbook, pas comme une insulte personnelle.

Blague n°1 : Un écran noir, c’est juste la façon qu’a votre ordinateur de demander moins de surprises et plus de journaux. Il n’a pas tort.

Les 6 correctifs qui résolvent généralement le problème

Tâches pratiques : commandes, ce que signifie la sortie, et vos décisions

Voici des tâches réelles que j’exécute en mode incident. Chaque élément inclut : la commande, une sortie d’exemple, ce que cela signifie et la décision à prendre.

Task 1: Confirm whether you can reach a TTY and what kernel you’re on

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

Ce que cela signifie : Le noyau tourne. Ce n’est pas un problème de « ne peut pas démarrer » ; c’est un problème de « pas de session utilisable » (GUI, pilotes, services ou délais de stockage).

Décision : Concentrez‑vous sur les journaux (Tâche 2/3) et l’affichage/GPU (Tâches 6–10), pas sur une chirurgie GRUB pour l’instant.

Task 2: Inspect the previous boot’s critical errors

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'.

Ce que cela signifie : La signature ou la vérification du module est en cause, et GDM échoue parce que la pile GPU ne s’est pas mise en place.

Décision : Allez au Correctif 4 (Secure Boot/MOK) et au Correctif 2 (récupération du pilote). Ne perdez pas de temps à réinstaller GNOME inutilement.

Task 3: Find the boot stage where the system stalls

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

Ce que cela signifie : Le noyau et systemd sont vivants ; une unité de device (partition NVMe) monopolise plus d’une minute. C’est souvent des timeouts, des réessais ou un disque instable.

Décision : Traitez comme un problème de fiabilité de stockage (Correctif 5). Attendez‑vous à voir des timeouts NVMe dans dmesg.

Task 4: Check dmesg for GPU resets, storage timeouts, or firmware missing

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

Ce que cela signifie : Plusieurs signaux d’alerte : timeouts de stockage, récupération ext4, et firmware i915 manquant. Chacun de ces éléments peut conduire à un écran noir.

Décision : Priorisez la santé du stockage et les paquets de firmware. Si le disque meurt, aucun réglage d’affichage ne vous sauvera.

Task 5: Verify free space (a boring check that fixes surprising boot issues)

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

Ce que cela signifie : Le root est plein. Les services qui ont besoin d’écrire (gdm, journald, apt triggers, sessions utilisateur) vont échouer de façons étranges, y compris boucles de connexion et écrans noirs.

Décision : Libérez de l’espace immédiatement (journaux, anciens noyaux, caches). Puis relancez la configuration des paquets en attente et reconstruisez initramfs si nécessaire (Correctif 3).

Task 6: Check which GPU and driver stack the system thinks it has

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

Ce que cela signifie : i915 est le pilote actif. L’écran noir peut venir du firmware, d’une régression du noyau, ou du comportement du gestionnaire d’affichage/Wayland.

Décision : Si dmesg montre des échecs de chargement de firmware, installez le firmware manquant et reconstruisez initramfs (Correctif 3). Si c’est lié à Wayland, essayez la bascule vers Xorg (Tâche 10).

Task 7: Check whether GDM is failing or looping

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'.

Ce que cela signifie : Le gestionnaire d’affichage n’a pas démarré une session fonctionnelle. Cela peut être le pilote GPU, un problème Wayland, des permissions, ou des symptômes d’un disque plein.

Décision : Récupérez les journaux de GDM (Tâche 8) et décidez si vous devez basculer sur Xorg ou utiliser temporairement un autre gestionnaire d’affichage pour confinement.

Task 8: Extract the GDM and GNOME Shell logs from the current boot

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

Ce que cela signifie : « No session desktop files » suggère des paquets endommagés ou une mise à jour partiellement achevée, pas uniquement un problème GPU.

Décision : Validez l’état des paquets (Tâche 11), puis réinstallez les paquets de session de bureau si nécessaire. Ne continuez pas à redémarrer dans l’espoir que ça se corrige tout seul.

Task 9: Temporary “nomodeset” boot to get a working console/GUI baseline

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

Ce que cela signifie : nomodeset est activé de façon persistante dans GRUB. Cela permet souvent le démarrage mais désactive l’accélération GPU correcte et peut limiter les résolutions.

Décision : Utilisez‑le seulement comme béquille de diagnostic. Une fois le pilote/firmware réel réparé, retirez nomodeset et régénérez GRUB (Tâche 16).

Task 10: Force GDM to use Xorg instead of Wayland (common containment move)

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

Ce que cela signifie : Wayland est désactivé pour GDM. Cela stabilise souvent les systèmes avec certains paramètres NVIDIA ou des régressions de composition.

Décision : Si cela résout l’écran noir, conservez‑le comme mitigation court terme et planifiez une fenêtre pour mettre à jour pilote/noyau ultérieurement.

Task 11: Check for a broken upgrade (half-configured packages, DKMS failures)

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

Ce que cela signifie : Le paquet noyau n’a pas fini de se configurer — souvent à cause d’un échec de génération d’initramfs, d’un disque plein, ou d’une erreur DKMS.

Décision : Corrigez les prérequis (espace, erreurs DKMS), puis exécutez dpkg --configure -a et reconstruisez initramfs (Correctif 3).

Task 12: Rebuild initramfs for all 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

Ce que cela signifie : Les images initramfs ont été générées avec succès. Si vous avez vu des erreurs ici, elles comptent ; faites défiler et corrigez-les plutôt que de redémarrer dans l’espoir.

Décision : Si la génération réussit, mettez à jour GRUB et redémarrez. Si elle échoue à cause de DKMS, traitez la construction/signature du module d’abord (souvent Correctif 4 pour Secure Boot).

Task 13: Identify installed kernels and pick a fallback in 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

Ce que cela signifie : Vous avez au moins deux noyaux. C’est votre filet de sécurité.

Décision : Si 6.8.0-41 échoue, démarrez 6.8.0-40 depuis « Advanced options for Ubuntu » et réparez depuis là (Correctif 3 / Correctif 2 selon les symptômes).

Task 14: Verify Secure Boot state from the running system

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

Ce que cela signifie : Secure Boot est activé, donc les modules tiers non signés peuvent être bloqués.

Décision : Si vous dépendez de NVIDIA ou d’autres modules DKMS, assurez‑vous que l’inscription MOK et la signature des modules sont correctes (Correctif 4). Ne réinstallez pas en boucle les pilotes sans traiter la signature.

Task 15: Check whether the NVIDIA kernel module is loaded (if applicable)

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

Ce que cela signifie : Le système utilise nouveau, pas le module propriétaire NVIDIA. Cela peut être intentionnel, ou cela peut indiquer que NVIDIA a échoué à se charger.

Décision : Si vous avez besoin du NVIDIA propriétaire pour CUDA/3D, vérifiez le journal pour des échecs de chargement de module et des problèmes Secure Boot (Correctif 4), puis réinstallez la version correcte du pilote (Correctif 2).

Task 16: Update GRUB config after changes

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

Ce que cela signifie : GRUB voit les deux noyaux et les images initramfs. Bien.

Décision : Si GRUB ne liste pas les images attendues, arrêtez et inspectez la capacité de /boot et la santé du système de fichiers (Correctif 5).

Task 17: Check EFI System Partition mount and free space (UEFI boot issues)

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

Ce que cela signifie : L’ESP est montée et inscriptible (pour l’instant). Si elle manque, les installations GRUB peuvent « réussir » sans pour autant être là où le firmware s’attend.

Décision : Si l’ESP n’est pas montée, montez‑la, vérifiez /etc/fstab, et réparez les entrées GRUB/EFI (Correctif 6).

Task 18: Run a filesystem check when the system is in emergency mode or from a live environment

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

Ce que cela signifie : La récupération du journal a eu lieu et le système de fichiers est maintenant propre.

Décision : Si fsck signale des erreurs non réparables ou des corruptions récurrentes, arrêtez de traiter cela comme un problème logiciel. Remplacez le disque et restaurez.

Trois mini‑récits en entreprise depuis le terrain

Mini‑récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne faisait tourner une flotte de postes Ubuntu pour des développeurs et quelques machines GPU sur site pour l’entraînement de modèles. Un lundi matin, plusieurs postes avaient été mis à jour pendant le week‑end et se retrouvaient « morts » : écran noir, ventilateurs qui tournent, pas d’interface graphique.

L’ingénieur de garde a supposé qu’il s’agissait d’une régression GNOME parce que « l’écran de connexion est noir, donc ça doit être le bureau ». Il a réinstallé à distance des paquets de bureau via un shell de secours, redémarré GDM, et essayé plusieurs gestionnaires d’affichage. Sans succès. Pendant ce temps, d’autres machines se mettaient à jour automatiquement et tombaient dans le même état.

Le vrai mode de panne : Secure Boot avait été activé dans le firmware sur une série d’ordinateurs portables suite à une politique de mise à jour BIOS. Le module du pilote GPU propriétaire n’était plus accepté sans inscription MOK correcte. Les machines démarraient bien ; c’était la pile graphique qui n’était pas chargée.

Le retournement est venu lorsqu’une personne a fait la chose peu glamour : journalctl -b -p err et l’a lu de bout en bout. Les erreurs de vérification des modules étaient là, évidentes. Une fois qu’ils se sont alignés sur l’inscription MOK pendant l’installation des pilotes ou qu’ils ont temporairement basculé les machines affectées sur Xorg, la flotte s’est remise rapidement.

La leçon n’était pas « Secure Boot mauvais ». C’était « les hypothèses coûtent cher ». Quand l’écran est noir, les journaux du noyau sont votre réalité.

Mini‑récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulait accélérer la conformité des correctifs sur les postes des employés. Ils ont réglé les unattended upgrades pour appliquer automatiquement et redémarrer la nuit. Sur le papier, parfait : moins de vulnérabilités connues en attente, moins de redémarrages manuels, moins de « je le ferai plus tard ».

Puis une incompatibilité pilote‑noyau a touché un sous‑ensemble de machines avec GPU discret. Le redémarrage silencieux a eu lieu à 3 h du matin. Le lendemain, les utilisateurs sont arrivés face à des écrans noirs et une file d’assistance qui ressemblait à une attaque par déni de service — mais auto‑infligée.

L’« optimisation » consistait à supposer que les redémarrages sont des opérations sans risque. En réalité, un redémarrage est un changement de production : noyau, initramfs, pilotes, firmware et bootloaders sont tous sollicités. Si vous n’avez pas de déploiements par paliers, de canaris, ou au moins une garde‑fou « ne pas redémarrer si le dernier démarrage était mauvais », vous jouez à la roulette à grande échelle.

Ils ont corrigé en mettant en place des déploiements par paliers (même un calendrier en anneaux rudimentaire), en conservant au moins deux noyaux connus bons, et en s’assurant que l’accès distant restait disponible (SSH activé, accès console documenté). Les unattended upgrades sont restées — mais avec des garde‑fous. Ennuyant, efficace.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation financière utilisait Ubuntu sur quelques centaines d’ordinateurs portables et des postes partagés. Leur posture de sécurité était stricte, donc Secure Boot restait activé. Ils avaient aussi une pratique simple mais disciplinée : chaque machine conserve deux noyaux installés, et ils validaient régulièrement que GRUB affichait « Advanced options » avec plusieurs entrées.

Quand une mise à jour de noyau a causé une régression sur un modèle matériel particulier, ils n’ont pas eu besoin d’héroïsme. Les utilisateurs devaient simplement sélectionner le noyau précédent dans GRUB. L’IT avait un petit script pour marquer la version de noyau problématique et bloquer les mises à jour jusqu’à la correction.

Ce qui a fait la différence n’était pas un génie technique. C’était la mémoire opérationnelle : « Si un noyau nouveau échoue, démarrez l’ancien, collectez les journaux, puis corrigez. » Ils avaient aussi l’habitude de vérifier l’espace libre sur / et /boot lors des maintenances, ce qui a évité la classique défaillance de génération d’initramfs due à un système de fichiers plein.

L’incident n’est pas devenu une crise parce que l’organisation traitait la capacité de démarrer comme une fonctionnalité de fiabilité — testée, préservée et documentée. La prévisibilité bat l’ingéniosité.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: Black screen, but you can SSH in

• Cause racine : Le gestionnaire d’affichage (GDM) échoue à cause d’une incompatibilité du pilote GPU, de problèmes Wayland, ou d’un disque plein.
• Correctif : Vérifiez systemctl status gdm et journalctl -u gdm. Si NVIDIA, validez le chargement du module et Secure Boot (Correctif 4). Essayez la bascule Xorg (Correctif 2 / Tâche 10). Vérifiez l’utilisation du disque (Tâche 5).

2) Symptom: Boot loop after kernel update; GRUB appears briefly

• Cause racine : Initramfs cassé ou échec postinst du noyau ; parfois DKMS a échoué pendant la mise à jour.
• Correctif : Démarrez sur un noyau plus ancien, exécutez dpkg --configure -a, puis update-initramfs -u -k all et update-grub (Correctif 3).

3) Symptom: “Started GNOME Display Manager” never appears; long stalls

• Cause racine : Délais de stockage (timeouts NVMe), attentes fsck, ou disque défaillant.
• Correctif : Utilisez systemd-analyze blame et filtrez dmesg pour nvme/I/O (Tâches 3/4). Exécutez fsck si nécessaire (Tâche 18). Remplacez le matériel suspect (Correctif 5).

4) Symptom: Login loop (enter password, returns to login)

• Cause racine : Disque plein, fichiers de session utilisateur cassés, mauvaises permissions dans le home, ou plantage GDM/Wayland.
• Correctif : Vérifiez df -h, libérez de l’espace ; inspectez journalctl pour les erreurs de session ; essayez la bascule Xorg ; confirmez les permissions du dossier home. Redémarrez gdm après correction.

5) Symptom: Black screen immediately after selecting Ubuntu in GRUB

• Cause racine : Régression modesetting du noyau ou deadlock du pilote GPU tôt dans le démarrage.
• Correctif : nomodeset temporaire dans GRUB pour démarrer, puis réparez le pilote/firmware et retirez nomodeset (Correctif 2).

6) Symptom: No GRUB menu; straight to firmware or “no boot device”

• Cause racine : Entrée de boot EFI manquante, ESP corrompue/non montée, disque non détecté.
• Correctif : Vérifiez l’ordre de boot dans le firmware, montez l’ESP, réinstallez GRUB en mode UEFI via chroot si nécessaire (Correctif 6). Si le disque est absent, c’est matériel.

Listes de contrôle / plan étape par étape

Checklist A: If you can reach a TTY or SSH (most common case)

1. Confirmez que le noyau tourne : uname -a.
2. Récupérez les erreurs du démarrage précédent : journalctl -b -1 -p err.
3. Vérifiez l’espace disque : df -h / et aussi df -h /boot, df -h /boot/efi.
4. Vérifiez le statut de GDM : systemctl status gdm et journalctl -u gdm.
5. Vérifiez l’état du pilote GPU : lspci -nnk, lsmod, et dmesg -T pour les erreurs drm/gpu.
6. Si NVIDIA + Secure Boot activé : confirmez avec mokutil --sb-state et décidez l’inscription MOK (Correctif 4).
7. Réparez l’état des paquets : dpkg --audit, puis dpkg --configure -a si nécessaire.
8. Reconstruisez initramfs : update-initramfs -u -k all, puis update-grub.
9. Confinement si nécessaire : forcez Xorg dans /etc/gdm3/custom.conf et redémarrez gdm.
10. Redémarrez une fois — un redémarrage propre, pas cinq répétés — puis revérifiez les journaux.

Checklist B: If you cannot reach TTY/SSH (bootloader/initramfs path)

1. Au démarrage, forcez l’affichage du menu GRUB (maintenez Shift ou appuyez sur Esc selon le firmware).
2. Essayez « Advanced options » et démarrez sur un noyau plus ancien.
3. Essayez le mode recovery et « root » shell. Si vous obtenez un shell, poursuivez Checklist A depuis l’inspection des journaux et des disques.
4. Si aucun noyau installé ne démarre : utilisez un live ISO Ubuntu, montez root, chroot, puis reconstruisez initramfs et réinstallez GRUB (Correctif 3 + Correctif 6).
5. Vérifiez le montage de l’ESP et reconstruisez les entrées de boot EFI.
6. Ce n’est qu’après l’échec des remédiations logicielles que vous devez suspecter le matériel du disque/contrôleur.

Checklist C: The “stop making it worse” rules

• N’éliminez pas des paquets au hasard avant d’avoir capturé les journaux depuis journalctl -b -1 et dmesg.
• Ne redémarrez pas en boucle ; vous écrasez les preuves et vous fatiguez du matériel en panne.
• Ne laissez pas le système bloqué sur nomodeset en permanence sauf si c’est un kiosque et que vous acceptez une basse résolution et des comportements étranges.
• Ne désactivez pas Secure Boot de façon permanente par réflexe. Décidez en connaissance : politique de sécurité vs simplicité opérationnelle.

FAQ

1) How do I know if it’s “just the GUI” and not the whole system?

Si vous pouvez basculer vers un TTY (Ctrl+Alt+F3) ou vous connecter en SSH, le noyau a démarré et systemd fonctionne. Vous déboguez alors l’affichage/gestionnaire ou des délais de stockage tardifs, pas GRUB.

2) Does “nomodeset” fix the problem?

Non. Il permet souvent d’atteindre un démarrage en évitant le kernel modesetting, ce qui vous donne une base pour réparer pilotes/firmware. Traitez‑le comme une roue de secours.

3) Why does an NVIDIA driver update cause a black screen after a kernel update?

La pile NVIDIA propriétaire dépend des interfaces noyau et compile des modules (souvent via DKMS). Si la compilation du module échoue, ou si Secure Boot le bloque, la pile d’affichage ne peut pas démarrer.

4) What’s the quickest single log command that usually tells the truth?

journalctl -b -1 -p err est un excellent point de départ, surtout après une boucle de démarrage. Il filtre les erreurs du démarrage précédent, quand l’échec s’est produit.

5) Can a full disk really cause a black screen?

Oui. GDM, GNOME Shell et même des composants d’authentification ont besoin d’écrire des fichiers. Si / est plein, vous pouvez obtenir des boucles de connexion, des échecs de session et un « bureau » vide.

6) Should I switch from Wayland to Xorg?

Si vous êtes bloqué et devez rendre la machine utilisable aujourd’hui, oui — forcer GDM sur Xorg est une mesure de confinement raisonnable. Planifiez ensuite de corriger le pilote/noyau sous‑jacent.

7) How do I recover if I can’t even see the GRUB menu?

Tentez de le forcer avec Esc/Shift pendant le démarrage. Si le firmware ne passe jamais la main à GRUB, vous pouvez avoir besoin d’un live ISO pour réparer l’entrée de boot EFI et réinstaller GRUB (Correctif 6).

8) Is this more common on desktops than servers?

Oui. Les serveurs tournent souvent sans GUI et avec des besoins de pilote plus conservateurs. Les postes de bureau combinent GPU, compositeurs et changements fréquents de pilotes — plus d’éléments mobiles, plus de modes de panne.

9) If fsck “fixes” things once, am I done?

Pas forcément. Une récupération après un arrêt non propre est normale. Des réparations répétées du système de fichiers ou des timeouts NVMe récurrents sont un signal de fiabilité : surveillez SMART/état et planifiez un remplacement.

Conclusion : étapes suivantes pour prévenir la réapparition

Les écrans noirs et boucles de démarrage sur Ubuntu 24.04 ne sont que rarement mystérieux. Ils correspondent généralement à l’un des six éléments suivants : pilotes GPU, mismatch noyau/initramfs, politique de module Secure Boot, gestionnaire d’affichage/Wayland, défaillances de stockage/système de fichiers, ou dérive GRUB/EFI. L’astuce est d’identifier vite l’étape d’échec, puis d’appliquer le correctif qui correspond aux preuves.

Étapes suivantes qui réduisent réellement la douleur future :

• Conservez au moins deux noyaux installés et vérifiez que GRUB les affiche.
• Faites des vérifications régulières d’espace libre pour /, /boot et /boot/efi.
• Si vous utilisez NVIDIA et Secure Boot, standardisez l’inscription MOK et la procédure de signature des modules plutôt que d’improviser machine par machine.
• Déployez les mises à jour et les redémarrages par paliers. Un redémarrage est un événement de changement, que vous le respectiez ou non.
• Quand quelque chose casse, capturez journalctl -b -1 avant de commencer à « réparer ». Les journaux ne mentent pas ; les humains, si.