Discussion :

[Mathis Lucas]

Une nouvelle mise à jour de Systemd permettra à Linux de bénéficier de l'infâme "écran bleu de la mort" de Windows
mais la fonctionnalité a reçu un accueil très mitigé

Linux est en train de se doter de sa propre version de l'écran bleu de la mort (Blue Screen of Death - BSOD). La dernière mise à jour de Systemd s'accompagne d'un service "systemd-bsod" capable de générer un message d'erreur en plein écran sur les distributions Linux. Il fournira des messages d'erreur significatifs et un code QR permettant aux utilisateurs d'obtenir rapidement plus d'informations sur l'erreur qu'ils ont rencontrée. L'outil arrive juste à temps pour les distributions Linux H1 2024, ce qui signifie que les distributions Linux en cours de déploiement devraient le prendre en charge. Les réactions face à l'annonce de cette fonctionnalité sont toutefois mitigées.

Systemd est une suite de composants de base pour une distribution Linux. Il fournit un gestionnaire de système et de services qui s'exécute en tant que PID 1 et démarre le reste du système. Systemd est utilisé par Debian, Arch, Fedora, Ubuntu et de nombreuses distributions en aval. La version 225 de Systemd vient d'être publiée avec une nouveauté empruntée à Windows. Elle introduit le composant "systemd-bsod" qui affichera "l'écran bleu de la mort" de Windows en cas d'échec du démarrage. Un systemd-bsod peut être affiché lorsqu'un niveau de journal LOG_EMERG est atteint, ressemblant au tristement célèbre écran de défaillance du système Windows.

Semblable au BSOD des versions récentes de Windows, le nouvel écran d'erreur de Systemd présente un code QR que les utilisateurs peuvent scanner pour en savoir plus sur le problème. De plus, il affiche les messages d'erreur enregistrés en plein écran, ce qui permet aux utilisateurs expérimentés ou aux techniciens d'obtenir plus d'informations sur les problèmes potentiels. La fonctionnalité a été initialement rapportée par le média informatique Phoronix. Le média indique que la fonctionnalité a été ajoutée dans le cadre d'un projet communautaire appelé Outreachy, un groupe qui propose des stages aux personnes travaillant sur des outils open source.

La fonction systemd-bsod est encore expérimentale, et le journal des modifications de GitHub indique qu'elle est encore sujette à des changements, mais Systemd est un élément essentiel de la plupart des distributions Linux. En outre, cette fonctionnalité arrive juste à temps pour les distributions Linux H1 2024. Il est donc probable que les utilisateurs de distributions Linux en cours de déploiement voient cet écran bleu de la mort plus tôt, à condition qu'ils rencontrent une erreur. Et cette fonctionnalité BSOD devrait être largement adoptée au cours de l'année 2024. Chez les utilisateurs des distributions Linux concernées, les réactions sont plutôt mitigées.

« C'est une fonction tellement inutile. J'ai plusieurs systèmes Linux pour mon travail quotidien. Ils fonctionnent pendant des mois, parfois des années. La seule fois où je vois une panique du noyau, c'est lorsque le matériel est mauvais ou lorsque j'ai fait quelque chose de mal (mauvaise configuration). Il y a quelques années, j'avais un système à double amorçage avec une mauvaise RAM et sous Windows, il affichait régulièrement des écrans bleus, alors que sous Linux, tout allait bien. Il m'a fallu beaucoup de temps pour comprendre quel était le problème réel, car Linux est tellement solide comme un roc », note un critique. Un autre a écrit :

Mon sentiment est mitigé. D'une part, Systemd capitalise sur les attentes existantes des utilisateurs et des administrateurs - ce qui, à mon avis, est généralement une bonne chose (quand la machine fait une chose que l'utilisateur comprend). D'autre part, le projet reproduit une caractéristique infâme qui est indigne et désobligeante - comme s'il fallait vraiment que ce soit bleu. Pourquoi pas le gris, le vert ou autre chose pour laisser à Windows sa mauvaise réputation ?

Par ailleurs, est-ce le mieux que nous puissions faire ? N'y a-t-il pas un meilleur moyen d'enregistrer les données des messages d'erreur pour les examiner au prochain démarrage ou dans un fichier ou quelque part où le même avantage peut être obtenu ?

En effet, BSOD est censée être un outil de diagnostic, un écran d'information que les techniciens peuvent utiliser pour commencer à identifier le problème à l'origine de la panne. Microsoft a introduit le BSOD avec Windows NT 3.1 en 1993, et il est devenu depuis l'un des aspects les plus redoutés du système d'exploitation en raison de la difficulté pour les utilisateurs non avertis de trouver des informations utiles sur les erreurs. En 2016, la firme de Redmond a ajouté des codes QR aux BSOD à partir de Windows 10. Cependant, les codes menaient initialement à des pages d'aide génériques ne contenant aucune information sur l'erreur spécifique incriminée.

L'écran bleu de la mort de Windows

Les informations étaient souvent si larges et si vagues qu'elles étaient inutiles. Toutefois, certaines sources suggèrent que le BSOD de Linux fournit plus d'informations utiles que la fameuse version de Windows. Pour l'instant, l'on ne trouve pas de capture d’écran du message d'erreur de systemd-bsod ni d'explication sur la raison de son adoption. D'autres critiques trouvent la nouvelle surprenante, car Linux possède déjà sa propre version du message d'erreur connu sous le nom de "kernel panic". Mais l'ajout des codes QR pourrait permettre aux utilisateurs de Linux de résoudre plus facilement les erreurs majeures de leur distribution.

La nouvelle version de Systemd comporte également des dizaines d'autres fonctionnalités et correctifs qui, selon les critiques, sont plus utiles et plus importants que la nouvelle fonctionnalité d'écran bleu de la mort de Linux. Cela inclut de nombreux ajouts liés à la prise en charge des TPM, au chiffrement des disques et à la possibilité d'utiliser la mise en veille prolongée avec les systèmes de fichiers btrfs. Entre-temps, Microsoft a expérimenté des modifications du message d'erreur BSOD. Le BSOD est brièvement devenu noir dans Windows 11 avant que Microsoft ne revienne sur ce changement peu après la sortie du système d'exploitation en 2021.

Source : systemd v255

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'arrivée de l'écran bleu de la mort sous Linux ?
Selon vous, cette fonctionnalité est-elle utile pour les distributions Linux ? Pourquoi ?

Voir aussi

Lennart Poettering, le créateur de Systemd, aurait quitté Red Hat pour Microsoft, l'entreprise emploie actuellement l'inventeur de Python Guido van Rossum, l'inventeur de GNOME Miguel de Icaza

Le support de Systemd est disponible dans le sous-système Windows pour Linux et améliore la gestion des processus et des services, WSL prend également en charge plus d'applications

systemd a désormais plus de 1,2 million de lignes de code qui sont réparties sur 3260 fichiers, et proviennent de près de 1400 auteurs différents

[pokap]

Ça ne me dérange pas qu'il ajoute cette fonctionnalité, par contre si je le rencontre une seule fois et que ce n'est pas à cause d'un soucis matériel, ça voudra dire qu'il faut changer de distribution.

[calvaire]

Il y a quelques années, j'avais un système à double amorçage avec une mauvaise RAM et sous Windows, il affichait régulièrement des écrans bleus, alors que sous Linux, tout allait bien.

j'ai eu le meme cas il y'a 10ans sur mon pc !
j'ai pu découvrir l'erreur en testant avec la ram qu'un pote m'a preté.

les bsod de windows c'est de la merde, ca donne de la doc générique ou il est impossible de trouver la vrai erreur. j'ai jamais compris pourquoi MS donnait des nom de code foireux (0xc0000001234) a ces erreurs aau lieu de les afficher clairement. c'est pas compliquer d'afficher des logs.

dans linux, une erreur c'est un vrai fichier de log avec l'adresse du bus pci/usb ou autres bien précise et donc c'est assez facile de debugger.
un bsod dans linux est inutile.

[disedorgue]

A une époque, on disait que linux était un mélange du meilleur des monde unix (bsd vs system 5) , là il cherche peut-être à prendre le meilleur des monde de windows

[LittleWhite]

@calvaire : autant que je sache, le vrai log des BSOD c'est dans le moniteur événements (j'ai oublié le nom exact, c'est dans les outils d'administration du panneau de configuration (l'historique, pas les nouveaux panneaux ).
Je peux comprendre que dans le BSOD, il n'y ai pas nécessairement un message clair, juste un code. Sous Linux, c'est un dump des registres du CPU et une stacktrace. Pourquoi je peux le comprendre, car lorsque cela se produit, généralement, le noyau, il est mal. Si vous tentez d'accéder à plus au moment où le noyau est planté (une table de correspondance entre les codes erreurs et un message utilisateur propre (et traduit ?) , bah, vous risquez d'empirer une situation déjà catastrophique. Donc, en cas d'erreur, je comprends que l'on n'exécute que l'immédiatement urgent.
Après, Microsoft ne veut pas non plus dévoilé leurs secrets, donc l'absence d'informations exacts, ça peut aussi se comprendre.

[Patrick Ruiz]

Linux sera bel et bien doté de « l’écran bleu de la mort » de Windows à partir de la version 6.10 du noyau
Et ce, même si des observateurs estiment que c’est une fonctionnalité inutile pour les linuxiens

Linux sera bel et bien doté de sa propre version de l'écran bleu de la mort (Blue Screen of Death - BSOD). Linux 6.10 est attendu pour le milieu ou la fin du mois de septembre 2024 et c’est avec cette mouture du noyau que sera livré « l’écran bleu de la mort » qui rappelle Windows et pour lequel des observateurs sont d’avis que c’est une fonctionnalité inutile pour les linuxiens.

Pour ceux qui sont curieux de savoir à quoi il peut ressembler, Javier Martinez Canillas, ingénieur chez Red Hat, a partagé une photo de ce dernier en action.

À l'instar de l'écran bleu de la mort qui a vu le jour sous Windows, la version de Linux sera utilisée comme outil d'urgence pour enregistrer les erreurs. Si un système Linux ne parvient pas à démarrer, il génère un message en plein écran qui affiche un code QR permettant d'obtenir plus d'informations sur la cause du problème de démarrage.

BSOD est donc censé être un outil de diagnostic, un écran d'information que les techniciens peuvent utiliser pour commencer à identifier le problème à l'origine de la panne. Microsoft a introduit le BSOD avec Windows NT 3.1 en 1993, et il est devenu depuis l'un des aspects les plus redoutés du système d'exploitation en raison de la difficulté pour les utilisateurs non avertis de trouver des informations utiles sur les erreurs.

En 2016, la firme de Redmond a ajouté des codes QR aux BSOD à partir de Windows 10. Cependant, les codes menaient initialement à des pages d'aide génériques ne contenant aucune information sur l'erreur spécifique incriminée. La fonctionnalité a reçu un accueil mitigé par les linuxiens, notamment, pour ce qui est de sa ressemblance avec la version Windows.

Son utilité réelle est également sujette à controverse. « Dans linux, une erreur est consignée dans un vrai fichier de log avec l'adresse du bus pci/usb (ou autres) bien précise et donc c'est assez facile de debugger. Un BSOD dans linux est inutile », commente un membre de developpez.com.

« C'est une fonction tellement inutile. J'ai plusieurs systèmes Linux pour mon travail quotidien. Ils fonctionnent pendant des mois, parfois des années. La seule fois où je vois une panique du noyau, c'est lorsque le matériel est mauvais ou lorsque j'ai fait quelque chose de mal (mauvaise configuration). Il y a quelques années, j'avais un système à double amorçage avec une mauvaise RAM et sous Windows, il affichait régulièrement des écrans bleus, alors que sous Linux, tout allait bien. Il m'a fallu beaucoup de temps pour comprendre quel était le problème réel, car Linux est tellement solide comme un roc », commente un autre.

Et vous ?

Partagez-vous les avis selon lesquels l’écran bleu de la mort est inutile en tant qu’outil de diagnostic sous Linux ?

Voir aussi :

Lennart Poettering, le créateur de Systemd, aurait quitté Red Hat pour Microsoft, l'entreprise emploie actuellement l'inventeur de Python Guido van Rossum, l'inventeur de GNOME Miguel de Icaza

Le support de Systemd est disponible dans le sous-système Windows pour Linux et améliore la gestion des processus et des services, WSL prend également en charge plus d'applications

systemd a désormais plus de 1,2 million de lignes de code qui sont réparties sur 3260 fichiers, et proviennent de près de 1400 auteurs différents

[calvaire]

j'ai jamais pu debbuger un soucis sous windows avec ces bsod.

honnêtement balancer un plein écran une erreur X02abcbuild1234fezasx00001 et quand on tape sur google l'erreur on trouve pleins de cause possible sans solutions...

alors que sous linux au moins les logs montre les erreurs simplement et c'est facile à débeugger.
j'ai eu une erreur une fois d'une lib qu'il n'arrivait pas à charger suite à une maj qui a cassé un pakcage.
j'ai démaré en mode rescue et j'ai ajouté la lib à la main et voila problème réglé.

Je comprends pas pourquoi windows n'évolue pas vers ca, vers des logs d'erreurs plus simple et plus compréhensible plutôt que ce qrcode.

[gabriel21]

Je comprends pas pourquoi windows n'évolue pas vers ca, vers des logs d'erreurs plus simple et plus compréhensible plutôt que ce qrcode.

Plus facile de vendre un support aux entreprises.

Plus sérieusement, j'espère que l'on pourra désactiver cette fonctionnalité qui a part nous faire perdre du temps, ne servira à rien sauf peut être pour les utilisateurs de Red Hat ayant une souscription payante car les code QR de Red Hat renverront très probablement directement sur la documentation réservé à des souscriptions valides.

Ma philosophie en cas de Kernel Panic :

1. Si aucune modification matérielle ou logicielle a été effectuée : redémarrer
2. Si une modification de noyau à eu lieu : redémarrer avec le noyau précédent
3. Si une modification matériel a eu lieu : retirer le matériel en question et redémarrer
4. Si aucune solution fonctionne, tenter un démarrage à partir d'un support amovible
5. Analyser les logs. Je ne le fais pas forcément, si un redémarrage a suffi et que cela ne se reproduit pas dans les 24h. Ce qui pourrait être le signe d'un composant qui commence à mourir.

[phil995511]

Plus facile de vendre un support aux entreprises.

Plus sérieusement, j'espère que l'on pourra désactiver cette fonctionnalité qui a part nous faire perdre du temps, ne servira à rien sauf peut être pour les utilisateurs de Red Hat ayant une souscription payante car les code QR de Red Hat renverront très probablement directement sur la documentation réservé à des souscriptions valides.

Ma philosophie en cas de Kernel Panic :

1. Si aucune modification matérielle ou logicielle a été effectuée : redémarrer
2. Si une modification de noyau à eu lieu : redémarrer avec le noyau précédent
3. Si une modification matériel a eu lieu : retirer le matériel en question et redémarrer
4. Si aucune solution fonctionne, tenter un démarrage à partir d'un support amovible
5. Analyser les logs. Je ne le fais pas forcément, si un redémarrage a suffi et que cela ne se reproduit pas dans les 24h. Ce qui pourrait être le signe d'un composant qui commence à mourir.

"Linux 6.10 introduit une nouvelle infrastructure de gestion de panique DRM permettant d'afficher un message lorsqu'une panique se produit. Ceci est particulièrement important pour ceux qui construisent un noyau sans le support VT/FBCON, car autrement, l'affichage du message de panique du noyau n'est pas facilement disponible.

Avec Linux 6.10, le code DRM Panic initial a atterri ainsi que le câblage de la prise en charge des pilotes DRM/KMS pour les pilotes SimpleDRM, MGAG200, IMX et AST. Des travaux sont en cours pour étendre la prise en charge de DRM Panic à d'autres pilotes, que nous verrons probablement au cours des prochains cycles du noyau pour une prise en charge plus étendue."

Source en anglais : https://www.phoronix.com/news/Linux-...c-BSoD-Picture

[chrtophe]

Quitte à mettre un truc inutile, j’aurais préféré un Guru Meditation (pour ceux pouvant comprendre). Et pour les machines en datacenter on fait comment ?

[Aspartame]

je suppose qu'on appelle cela une killer feature (SIC)

[23JFK]

J'suis mitigé... Si c'est juste pour ajouter un écran bleu abscons puis laisser l'utilisateur se dépatouiller avec les logs du système, ça ne sert à rien. Par contre, si le système est alors capable, comme le fait windows, de redémarrer, de s'auto-diagnostiquer puis de se réparer tout seul ; alors là OK... Mais on est alors plus sur un simple BSOD.

[Ti-Slackeux]

Par contre, si le système est alors capable, comme le fait windows, de redémarrer, de s'auto-diagnostiquer puis de se réparer tout seul ; alors là OK... Mais on est alors plus sur un simple BSOD.

> JayJay : et hop, ca marche ^^ windows c'est pratique, ca s'auto répare en un reboot.
> Savatte : clair, si ça s'auto cassait pas ca serait ultime

[23JFK]

Ouais, ça choque... Mais c'est pourtant une réalité, Windows arrive a se récupérer tout seul dans la plupart des kernel panic ; sous Linux ça reste épique.

[Ti-Slackeux]

Ouais, ça choque... Mais c'est pourtant une réalité, Windows arrive a se récupérer tout seul dans la plupart des kernel panic ; sous Linux ça reste épique.

Le kernel panic sous linux, comment dire ...
Je sais plus à quand remonte le dernier ...
Je ne vais pas dire que je n'en ai jamais fait tout comme je ne vais pas dire que j'ai jamais crash ma distro.
J'ai fait les deux à tour de bras à mes débuts sous Xénix / Sco / Linux, donc oui j'en ai fait.
Et merci les logs pour le dépannage.
Par contre avoir un bsod sous windows, j'ai rien à faire il arrive tout seul.
Et merci les codes abscons qui ne servent pratiquement jamais à rien.
Alors un bsod sous linux, tant que çà reste une option dans le kernel...

j’aurais préféré un Guru Meditation

Mouarf !!!
Et les petites bombes à côté du message d'erreur çà pourrait être sympa aussi non ????

[23JFK]

...

Là on est sur de la mauvaise fois Linuxienne. Depuis Windows10 les BSOD sont devenus plus rares que les librairies cassées sous Linux. Après les Logs, c'est bien, mais ce n'est pas demain que madame Michu va aller fouiner dans les fichiers systèmes pour réparer son OS, donc c'est un frein à l'adoption de Linux par les masses, même si le crash est devenu rare et qu'il commence à y avoir des distributions avec un système de récupération automatique.

[Escapetiger]

Quitte à mettre un truc inutile, j’aurais préféré un Guru Meditation (pour ceux pouvant comprendre). Et pour les machines en datacenter on fait comment ?

Je ne connaissais pas, alors pour la communauté, on adore la culture, surtout la notre tant qu'à faire:

What IS Guru Meditation?

Guru Meditation began as a warning message displayed by the Amiga computer when it crashed. It started as an inside joke in Amiga’s early days. When there was a fatal fault with the system, the alert was triggered. It is now used in prominent software packages like Virtual Box and Varnish.

I encountered the Guru Meditation error while trying to start up and also install new Virtual Machines(VMs) on my Virtual Box 7. Every time a VM started running, it would quickly display the Guru Meditation error after a few seconds as shown in the following screenshot.

Source: https://fossguides.com/causes-of-gur...how-to-fix-it/
Cause(s) of “Guru Meditation” Error in Virtual Box and How to Fix It – FOSSGuides


et question Guru, j'ai d'abord pensé à un site historique où vous avez peut-être fait vos armes comme moi

https://www.ugu.com/sui/ugu/showclassic
Unix Guru Universe

Copyright © 1994-2005 Unix Guru Universe

[chrtophe]

Et les petites bombes à côté du message d'erreur çà pourrait être sympa aussi non ????

Sur les très vieux Macintosh, avant Mac OS X, il y avait des crash qui affichait des bombes. Il me semble que le nombre de bombes donnait le numéro de l'exception levée.

Je ne connaissais pas, alors pour la communauté, on adore la culture, surtout la notre tant qu'à faire

En fait ça vient de l'Amiga, ça correspondait au BSOD. Ca a ensuite été repris dans d'autres produits.


Si je me souviens bien le 1er chiffre indiquait le numéro d'exception du 68000, le second chiffre l'adresse contenu dans le registre compteur d'instruction

[LittleWhite]

Sur les très vieux Macintosh, avant Mac OS X, il y avait des crash qui affichait des bombes. Il me semble que le nombre de bombes donnait le numéro de l'exception levée.

Je ne sais plus pour Macintosh, mais en tout cas, c'était le cas pour l'Atari ST