Comment afficher tous les messages de démarrage sous Linux après le démarrage?
Les questions pertinentes sont:
Où Linux place-t-il les messages de démarrage?
Nom du fichier journal dans lequel le processus de démarrage est enregistré
Cependant, ceux-ci ne répondent pas à cette question. Cette question concerne la façon dont tous les messages de démarrage peuvent être visualisés.
Ceci est pour Gentoo, OpenRC, les noyaux modernes, 4.9.6 si vous voulez être spécifique. Une solution générique qui fonctionne pour toutes les distributions serait toutefois préférable.
Le problème est que parfois une erreur ou un avertissement défile si rapidement qu'il est impossible de le voir. Il n’est pas toujours possible de faire simplement défiler vers le haut pour deux raisons (même avec --noclear in inittab): lors du passage au framebuffer, le défilement jusqu’au point précédant le changement de commutateur n’est plus possible, et ensuite, après le début de X, passer à la console et essayer de faire défiler vers le haut ne permet pas le défilement tant que le nouveau texte n'a pas été ajouté au tampon. Parfois, certains messages ne sont tout simplement pas trouvés dans dmesg, ni dans/var/log/messages.
Comment puis-je voir tous les messages?
Je vois quelqu'un ici https://www.linuxquestions.org/questions/linux-newbie-8/please-how-to-pause-scrolling-messages-at-boot-323772/ suggérant que le verrouillage du défilement pourrait le mettre en pause. Cependant, il s’agit au mieux d’une solution peu élégante: certains messages défileront trop rapidement, les systèmes peuvent soudainement produire beaucoup de texte au moment du démarrage.
C'est ce que je veux idéalement:
- Un dmesg | moins de solution de type, si possible, ou une autre manière d’avancer pas à pas dans le processus de démarrage.
- Une façon de s'assurer que tout ce qui est imprimé à l'écran est également enregistré.
Existe-t-il un moyen simple d’atteindre ces objectifs?
Je connais une solution:
CONFIG_BOOT_PRINTK_DELAY: Retarder chaque message printk de démarrage de N millisecondes.
Bizarrement, je ne semble même pas autorisé à sélectionner BOOT_PRINTK_DELAY dans mon menu, je peux le trouver lorsque je le cherche, mais sous Kernel hacking -> Options printk et dmesg ->, je n'ai que "Afficher les informations de synchronisation sur printks" et "Par défaut niveau du journal des messages ". Où est l'option de délai printk? Dois-je activer d'abord quelque chose d'autre pour le rendre visible? Quoi? Ce serait bien d'avoir cela dans le cadre d'une réponse, si quelqu'un le sait.
Quoi qu'il en soit, cela nécessite une recompilation du noyau, ce qui en fait un hack laid et envahissant pour une tâche apparemment triviale. Une façon appropriée de le faire serait la bienvenue.
Donc, votre console a deux types de messages:
- généré par le noyau (via printk);
- généré par l’espace utilisateur (généralement votre système init).
Les messages du noyau sont toujours stockés dans le tampon kmsg, visible via dmesg. Ils sont également souvent copiés dans votre syslog. (Ceci s'applique également aux messages de l'espace utilisateur écrits dans /dev/kmsg, mais ceux-ci sont assez rares.)
Pendant ce temps, lorsque l’espace utilisateur écrit son texte d’état de démarrage sophistiqué dans /dev/console ou /dev/tty1, il n’est stocké nulle part. Il va juste à l'écran et c'est tout. Je pense donc à peu près que n'importe quelle solution - à l'exception de la suggestion de la console série de Rowan - finira par être très spécifique à la distribution (en raison de la journalisation par chaque système init différemment) ou un "piratage invasif" impliquant le piratage de strace ou du noyau, etc.
Dans le meilleur des cas, votre système init va lui-même consigner tous les événements importants dans le syslog (/ var/log/messages ou autres). Par exemple:
systemd[1]: Starting BIRD routing daemon...
bird[478296]: /etc/bird.conf, line 2: syntax error
systemd[1]: bird.service: Control process exited, code=exited status=1
systemd[1]: Failed to start BIRD routing daemon.
(systemd et upstart enregistrent également le stdout/stderr des services; de nombreux autres systèmes init le redirigent simplement vers la console ou nulle part.)
Une suggestion est de laisser un autre ordinateur portable filmer l'écran de démarrage avec une résolution élevée et des fréquences d'images, puis ralentir la lecture du résultat ( MOV - MP4 - AVI ) - peut-être pas la meilleure solution mais simplement pour déployer et son pour le débogage de toute façon non? Juste une idée ...
La réponse de Grawity est qu'il faut mieux décrire ce que j'aurais pu accomplir pour cette étape du démarrage.
Sur la méthode de redirection physique, votre BIOS doit la prendre en charge. Les tableaux orientés serveur font habituellement. Les systèmes Intel, IBM et SuperMicro ont généralement une option de redirection de console sous l’en-tête principal du BIOS. Il ne peut pas être utilisé si votre carte mère ne possède pas de port série physique, par exemple. seulement USB. Vous devrez peut-être connecter un port physique aux broches de la carte mère, le cas échéant.
La redirection de console peut être délirante lorsque le système d'exploitation tente d'utiliser le port série pour autre chose. Je dirais qu'il est principalement utilisé pour le débogage dans un cas particulier plutôt que pour une utilisation constante.
Pour l'utiliser, vous devez définir des paramètres de port correspondants sur le port com de votre récepteur, qui pourraient être basés sur USB, puis relier les deux périphériques avec un câble null modem qui échange les broches de transmission et de réception entre les périphériques.
Le périphérique de réception doit être entièrement allumé et surveiller la communication lors du démarrage du système source. Le système de réception obtiendra toutes les sorties textuelles.
Si, pendant le démarrage, votre système d'exploitation commence à afficher du texte via une construction graphique plutôt que sous forme de texte, le système récepteur obtiendra du charabia.