L’écran bleu est souvent appelé BSOD, pour « bleu screen of death » (écran bleu de la mort). Pourquoi cette appellation ? Parce que depuis bien longtemps, sous Windows, son apparition signifie un plantage si important du système que la seule solution est de redémarrer le système.

Sa signification n’a pas changé, même aujourd’hui. Sa forme a évolué plusieurs fois, mais il est toujours bleu et a toujours la même signification : une erreur si grave que tout s’est bloqué. Le fait qu’il soit devenu bien plus rare qu’avant n’y fait rien.

Un outil d’information et de diagnostic

Ces dernières années, et dans l’immense majorité des cas, l’écran bleu est provoqué par un pilote de mauvaise qualité. Avec le temps et le passage des versions successives de Windows, les pilotes ont vu leur champ d’actions resserré sur l’espace utilisateur, ne laissant disponible l’espace noyau que dans quelques scénarios, dont le plus connu est le pilote graphique. La qualité générale s’est en outre beaucoup améliorée, grâce à une infrastructure plus stricte.

Avoir un écran bleu aujourd’hui est rare et toujours synonyme d’un sérieux problème. Il peut survenir à cause d’un pilote, d’un matériel défectueux, d’une tentative ratée d’overclocking ou encore du dépassement d’un certain seuil de température par le processeur.

Cela étant, le BSOD n’a pas que vocation à annoncer une mauvaise nouvelle : il fournit également des informations. La première est bien sûr d’indiquer qu’un gros problème s’est produit et que la session est devenue inutilisable. La deuxième qu’un vidage de la mémoire est en cours (indiqué par un pourcentage). Ce « dump » pourra se retrouver ensuite dans le journal des évènements. C’est une source d’informations précieuse dans les dépannages, car le fichier DMP contient les conditions ayant mené au crash.

Deux autres informations sont présentes : un code QR (apparu avec Windows 10) et un code d’arrêt. Le premier renvoie vers une page du site de Microsoft sur les écrans bleus, le second donne le type d’erreur ayant provoqué le plantage.

C'est quoi systemd ?

Avant de plonger dans la version 255 de systemd, présentons brièvement ce composant – ou plutôt cette série de composants – que l’on trouve dans la plupart des distributions Linux. Toutes les Debian, Ubuntu, Fedora ou encore Arch Linux s’en servent depuis longtemps.

Dans les grandes lignes, systemd est responsable de nombreux processus impliqués dans le démarrage de l’ordinateur, dont l’initialisation, c’est-à-dire le tout premier programme à être exécuté. Il fournit de nombreux outils et capacités comme la gestion des dépendances entre services, le chargement en parallèle de ces derniers, la journalisation des évènements ou encore la gestion des connexions des périphériques.

Notez que systemd est tellement vaste dans ses possibilités qu’il est entouré depuis longtemps d’une polémique sur son utilisation. Linuxfr.org y avait consacré un vaste dossier en 2015.

Un BSOD dans systemd

Et voilà qu’arrive la version 255 de systemd, avec à son bord l’équivalent d’un BSOD. Et l’équipe de développement ne s’en cache pas, puisque le nouveau composant est sobrement appelé « systemd-bsod ».

L’objectif est simple : tout évènement atteignant un niveau de journal LOG_EMERG affichera ses informations en plein écran. « EMERG » signifie ici « emergency » (urgence). Le niveau en question signifie que le système est devenu inutilisable. Des informations techniques sont donc fournies, y compris un code QR renvoyant vers de plus amples informations.

Cet ajout a été pensé comme une nouveauté utile, même si elle peut prêter à sourire. Il s’agit cependant d’une fonction présentée comme expérimentale et qui pourrait donc évoluer dans les prochains mois. La version 255 étant finale, elle sera intégrée – elle ou une mouture ultérieure – dans la prochaine vague de distributions prévues dans la première moitié de 2024, notamment les futures Ubuntu et Fedora.

Si cet ajout est vite devenu le plus visible, il est loin d’être le seul. Certains sont d’ailleurs beaucoup plus utiles, comme une meilleure prise en charge des puces TPM et du chiffrement intégral des disques, la possibilité d’utiliser l’hibernation avec des partitions Btrfs, ou encore l’utilisation des PIDFD au lieu des PID pour la plupart des processus internes. On trouvera la liste complète sur le dépôt GitHub officiel, mais Phoronix a trié les points les plus importants.