it-swarm.com.de

Wie zeige ich nach dem Booten alle Bootmeldungen in Linux an?

Relevante Fragen sind:

Wo legt Linux die Meldungen von boot ab?

Name der Protokolldatei, in der der Startvorgang protokolliert wird

Diese beantworten diese Frage jedoch nicht. Diese Frage beschäftigt sich damit, wie alle Startmeldungen angezeigt werden können.

Dies ist für Gentoo, OpenRC, moderne Kernel, 4.9.6, wenn Sie spezifisch werden möchten. Eine generische Lösung, die für alle Distributionen funktioniert, wäre jedoch vorzuziehen.

Das Problem ist, dass manchmal ein Fehler oder eine Warnung so schnell angezeigt wird, dass sie nicht sichtbar ist. Es ist auch nicht immer möglich, aus zwei Gründen einfach einen Bildlauf nach oben durchzuführen (auch mit --noclear in inittab): Wenn Sie auf den Framebuffer umschalten, ist ein Bildlauf bis zu dem Punkt vor dem Umschalten nicht mehr möglich, und zweitens, nachdem X gestartet wurde. Wenn Sie zur Konsole wechseln und versuchen, einen Bildlauf nach oben durchzuführen, können Sie erst dann einen Bildlauf durchführen, wenn dem Puffer neuer Text hinzugefügt wird. Manchmal werden bestimmte Nachrichten einfach nicht in dmesg oder/var/log/messages gefunden.

Wie kann ich alle Nachrichten anzeigen?

Ich sehe jemanden hier https://www.linuxquestions.org/questions/linux-newbie-8/please-how-pause-scrolling-messages-at-boot-323772/ was darauf hindeutet, dass das Drücken der Bildlaufsperre den Vorgang unterbrechen könnte. Dies ist jedoch bestenfalls eine nicht sehr elegante Lösung - einige Meldungen rollen zu schnell vorbei, und Systeme können heutzutage beim Booten plötzlich viel Text produzieren.

Das möchte ich im Idealfall:

  • Ein dmesg | Wenn möglich, weniger Lösungstypen oder eine andere Möglichkeit, den Startvorgang in Einzelschritten durchzuführen.
  • Eine Möglichkeit, um sicherzustellen, dass alles, was auf dem Bildschirm gedruckt wird, auch protokolliert wird.

Gibt es einen direkten Weg, um eines dieser Ziele zu erreichen?

Ich kenne eine Lösung:

CONFIG_BOOT_PRINTK_DELAY: Jede Boot-Printk-Nachricht wird um N Millisekunden verzögert

Seltsamerweise scheint es mir nicht erlaubt zu sein, BOOT_PRINTK_DELAY in meiner Menükonfiguration auszuwählen. Ich kann es bei der Suche finden, aber unter Kernel-Hacking -> Printk- und Dmesg-Optionen -> habe ich nur "Zeitinformationen auf Druckern anzeigen" und "Standard" Nachrichtenprotokollebene ". Wo ist die Druckverzögerungsoption? Muss ich zuerst etwas anderes aktivieren, um es sichtbar zu machen? Was? Es wäre schön, dies als Teil einer Antwort zu haben, wenn jemand weiß.

Dies erfordert jedoch eine Neukompilierung des Kernels, was dies zu einem hässlichen und invasiven Hack für eine scheinbar triviale Aufgabe macht. Eine ordnungsgemäße Vorgehensweise wäre sehr zu begrüßen.

Ihre Konsole verfügt also über zwei Arten von Nachrichten:

  • vom Kernel erzeugt (via printk);
  • vom Userspace generiert (normalerweise Ihr Init-System).

Kernel-Nachrichten werden immer im kmsg-Puffer gespeichert und über dmesg angezeigt. Sie werden auch häufig in Ihr Syslog kopiert. (Dies gilt auch für Userspace-Nachrichten, die in /dev/kmsg geschrieben wurden, aber diese sind ziemlich selten.)

Wenn der Userspace seinen ausgefallenen Boot-Status-Text in /dev/console oder /dev/tty1 schreibt, wird er in der Zwischenzeit nirgendwo gespeichert. Es geht einfach auf den Bildschirm und das wars. Ich denke also, dass so ziemlich jede Lösung - mit Ausnahme von Rowans Vorschlag für eine serielle Konsole - entweder sehr distro-spezifisch ist (da jedes Init-System die Protokollierung durchführt) anders) oder ein "invasiver Hack", der Strace- oder Kernel-Hacking oder ähnliches beinhaltet.

Im besten Fall protokolliert Ihr Init-System selbst alle wichtigen Ereignisse im Syslog (/ var/log/messages oder so). Zum Beispiel:

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 und upstart protokollieren auch das stdout/stderr der Dienste; viele andere init-Systeme leiten es einfach auf die Konsole oder nirgendwo weiter.)

6
grawity

Ein Vorschlag ist, einen anderen Laptop-Film über den Boot-Bildschirm mit hoher Auflösung und Bildwiederholungsrate abzuspielen, dann langsam das resultierende ( MOV-MP4-AVI ) - vielleicht nicht die beste lösung aber einfach zu implementieren und trotzdem für das debuggen oder? Nur eine Idee ...

1
Devuan

Die Antwort von Grawity muss besser beschrieben werden, als ich es in dieser Phase im Kofferraum hätte schaffen können.

Bei der physischen Umleitungsmethode muss Ihr BIOS dies unterstützen. Server Geared Boards tun dies normalerweise. Die Intel-, IBM- und SuperMicro-Systeme verfügen normalerweise über eine Konsolenumleitungsoption unter der Hauptüberschrift des BIOS. Es kann nicht verwendet werden, wenn Ihr Motherboard keinen physischen seriellen Anschluss hat, z. nur USB. Möglicherweise müssen Sie einen physischen Anschluss an die Stifte auf dem Motherboard anschließen, falls vorhanden.

Die Konsolenumleitung kann zu Problemen führen, wenn Sie den Punkt erreichen, an dem das Betriebssystem versucht, den seriellen Anschluss für einen anderen Zweck zu verwenden. Ich würde sagen, es wird in erster Linie zum Debuggen in einem bestimmten Fall und nicht zur ständigen Verwendung verwendet.

Zur Verwendung müssten Sie an Ihrem Empfänger-COM-Port die entsprechenden Port-Einstellungen vornehmen, die möglicherweise USB-basiert sind. Anschließend müssen Sie die beiden Geräte mit einem Nullmodemkabel verbinden, das die Sende- und Empfangspins zwischen den Geräten austauscht.

Das empfangende Gerät muss vollständig eingeschaltet sein und während des Startvorgangs des Quellsystems auf die Kommunikation achten. Das empfangende System erhält die gesamte textbasierte Ausgabe.

Wenn Ihr Betriebssystem während des Startvorgangs beginnt, Text über ein grafisches Konstrukt und nicht als Text anzuzeigen, wird das empfangende System verstümmelt.

1
Rowan Hawkins