Ich habe festgestellt, dass meine /var/log/boot.logDatei das Datum 22.04.2016 hat, als ich das letzte Mal in 15.10 gebootet habe. Wo befinden sich Xenial- boot.logDateien?
Ist echte Frage nicht Protokollierung, sondern zu sehen, was Boot verlangsamt. Jetzt benutzt du systemd-analyze blameund / oder systemd-analyze critical-chain . Ich finde das einfacher, als durch Protokolldateien zu graben, um herauszufinden, was ein Problem verursacht.
Oldfred
Keiner von euch kann also sagen, warum boot.log am 22.04.2016 stattfindet ...? JA WIRKLICH?
Jasmin
1
@jasmines: Leider können wir Ihnen nicht sagen, warum dies passiert ... wir sind nicht die Entwickler ... Ich habe meine Antwort mit einigen neuen Informationen von heute aktualisiert ... Sie sollten in Betracht ziehen, einen Fehlerbericht auf Launchpad einzureichen. :)
Cl-Netbox
2
journalctl zeigt nicht, was ich beim Booten im Splash sehe, und das brauche ich
Jasmin
1
Haben Sie es geschafft, das gut aussehende Protokoll mit "[FEHLGESCHLAGEN]" in Rot erneut zu erhalten? Meine Datei ist aus dem Jahr 2017 ...
Aquarius Power
Antworten:
33
Verwenden journalctl
Da journaldalle Protokolle enthalten sind, können Sie den journalctlBefehl mit geeigneten Filtern verwenden. In dem Fall von boot.log, der früher Nachrichten aus dem Init-System enthielt, können Sie Folgendes tun:
journalctl -b0 SYSLOG_PID=1
-b0Zeigt Meldungen vom aktuellen Start, -b1vom vorherigen Start usw. an. Ohne diese -bOption journalctlwerden Meldungen vom Beginn des Protokolls angezeigt.
SYSLOG_PID filtert Nachrichten von PID 1, aka init.
Oder:
journalctl -b0 --system _COMM=systemd
_COMM=systemdsucht nach Nachrichten aus dem systemdBefehl. Da systemdes sich um init handelt, ist dies derjenige, an dem wir interessiert sind.
--system Filtert Nachrichten aus dem Systemprotokoll anstelle von Benutzersitzungsprotokollen.
Beispiel:
muru@muru-vm:~$ journalctl -b0 SYSLOG_PID=1
Apr 30 12:29:18 muru-vm systemd[1]: systemd 229 running in system mode. (+PA
Apr 30 12:29:18 muru-vm systemd[1]: Detected virtualization qemu.
Apr 30 12:29:18 muru-vm systemd[1]: Detected architecture x86-64.
Apr 30 12:29:18 muru-vm systemd[1]: Set hostname to <muru-vm>.
Apr 30 12:29:18 muru-vm systemd[1]: Initializing machine ID from random gene
Apr 30 12:29:18 muru-vm systemd[1]: Installed transient /etc/machine-id file
Apr 30 12:29:18 muru-vm systemd[1]: Set up automount Arbitrary Executable Fi
Apr 30 12:29:18 muru-vm systemd[1]: Listening on fsck to fsckd communication
Apr 30 12:29:18 muru-vm systemd[1]: Reached target User and Group Name Looku
Apr 30 12:29:18 muru-vm systemd[1]: Listening on udev Kernel Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Started Forward Password Requests to Wal
Apr 30 12:29:18 muru-vm systemd[1]: Listening on /dev/initctl Compatibility
Apr 30 12:29:18 muru-vm systemd[1]: Listening on Journal Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice User and Session Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice System Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Starting Braille Device Support...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting POSIX Message Queue File System
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Debug File System...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Huge Pages File System...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Load Kernel Modules...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Uncomplicated firewall...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Create list of required static
lines 1-23
journalctlÖffnet die Protokolle standardmäßig in einem Pager, sodass Sie nicht weiterleiten müssen less.
journalctl zeigt nicht, was ich beim Booten im Splash sehe, und ich brauche das
Jasmin
1
Ich sehe, was in der Datei boot.log zuvor im folgenden Format protokolliert wurde: [OK] Started Self Monitoring and Reporting Technology (SMART) Daemon. Mounten beliebig ausführbarer Dateiformate Dateisystem ... [OK] Startete den Anmeldedienst. LSB starten: NTP-Daemon starten ... [OK] Avahi mDNS / DNS-SD Stack gestartet. [OK] Gestartet Stellen Sie entfernte CUPS-Drucker lokal zur Verfügung. [OK] Modem Manager gestartet. [OK] Startete Network Manager. Starten von Network Manager Online warten ... [OK] Zielnetzwerk erreicht. [OK] Started Accounts Service. und so weiter ...
Jasmin
1
Halte deinen Ton und deine Worte schön. Es gibt eine nette Politik. Folge es.
Seth
1
journalctl -bX ist dafür nutzlos, id enthält keine Meldungen, die während des Bootvorgangs wirklich auf dem Bildschirm erscheinen, nur boot.log und es funktioniert nur manchmal am 16.04. Die einzige Möglichkeit ist, ein Foto aufzunehmen oder es aufzuschreiben. Ich habe das gleiche Problem.
Mike
1
Wie bereits erwähnt, sind Startmeldungen, die mit [OK] beginnen, in der Datei boot.log enthalten. In journalctl ist dies jedoch ein wenig anders, auch wenn für vorherigen Start Flags wie -b0 SYSLOG_PID = 1 oder -b1 verwendet wurden, war dies nicht alles Dort sind speziell Fehler aufgetreten und ich konnte nirgends in Protokollen finden. Die meisten Nachrichten sind da, ich weiß nicht, wie ich dieses Problem reproduzieren soll, also kann ich nicht helfen, aber es war ein Fehler mit dem Kernel und es war nicht zu finden. Das Problem ist jetzt verschwunden, aber ich sehe immer noch keinen Grund, warum ich boote Nachrichten werden nicht genau so protokolliert, wie sie auf dem Bildschirm angezeigt werden.
Ich habe keine Ahnung, wie die Interna von Plymouth funktionieren, aber da es für den Begrüßungsbildschirm verantwortlich ist, der vor dem Anmeldebildschirm angezeigt wird, kann ich nur davon ausgehen, dass es keinen Begrüßungsbildschirm (schwarzen Bildschirm) gibt, bevor ich zum Anmeldebildschirm komme wird die Datei nicht verändert. Wenn vor dem Anmeldebildschirm ein Begrüßungsbildschirm angezeigt wird, wird die Ausgabe des Startvorgangs in die Datei boot.log umgeleitet.
Leider habe ich den Splash, aber kein boot.log ...
Jasmin
1
Ich bestätige, dass bei der Konfiguration GRUB_CMDLINE_LINUX_DEFAULT=""in /etc/default/grubals boot.lognicht geschrieben wird. Bei der Verwendung GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"als boot.logwieder geschrieben. Ich benutze Ubuntu 19.04.
Adrhc
2
In Ubuntu 16.04 befindet sich die boot.logDatei immer noch im /var/logOrdner, wie Sie hier sehen können . Das Boot-Logfile ist von heute (29.04.2016). Möglicherweise ist ein Fehler aufgetreten, als Sie Ubuntu 16.04 installiert oder das Betriebssystem von Ubuntu 15.10 auf Ubuntu 16.04 LTS aktualisiert haben.
Alternativ können Sie das allgemeine Startverhalten anhand der umfangreichen kern.logDatei untersuchen. Eine andere mögliche Alternative wäre, den Syslog-Daemon manuell zu konfigurieren , um die Boot-Protokolldatei zu generieren. Hier ist ein Tutorial, wie dies genau gemacht wird: So zeigen Sie Linux-Protokolle an und konfigurieren sie
Zusätzliche Information :
Ich habe das Verhalten der Startprotokollierung auf zwei verschiedenen Computern untersucht. Auf einem Computer mit einem UEFI-basierten BIOS ist die boot.logDatei vorhanden. Auf einem Computer mit einem älteren BIOS scheint sie jedoch überhaupt nicht zu existieren. Wenn das System also im alten BIOS-Modus (MBR / msdos) installiert ist, kann dies die Erklärung dafür sein, warum Ihre boot.logDatei vom 22.04.2016 stammt und ein Überbleibsel von Ubuntu 15.10 ist.
Aktualisierte Informationen 2016-05-02:
Ich habe das Verhalten der Boot-Protokolldatei weiter untersucht und festgestellt, dass die boot.logDatei noch auf dem UEFI-basierten Computer vorhanden ist, aber seit einigen Tagen ist die Datei leer. Eine andere Alternative, die ich versucht habe, um zu sehen, was während des Startvorgangs passiert, war die Installation von BootChart , die aber nach dem Neustart des Systems bootchart.pngnicht /var/logwie erwartet im Ordner vorhanden war. Es gab nur einen leeren /var/log/bootchartOrdner, der auch die erwartete bootchart.pngDatei nicht enthielt .
Aktualisierte Informationen 2016-05-04:
Heute boot.logschien die Datei wieder "Funktionalität" zu haben, sie ist mit Teilinformationen aus dem Bootvorgang gefüllt. Es scheint ein zufällig wechselndes Verhalten zu sein, das meines Erachtens auf Ask Ubuntu nicht gelöst werden kann. Sie sollten daher in Betracht ziehen, einen Fehlerbericht auf Launchpad einzureichen, um dieses Problem zu beheben.
Fazit - nach einer Woche Untersuchung des boot.logDateiverhaltens in Ubuntu 16.04: Sie sollten sich keine Gedanken /var/log/boot.logmehr machen und sich einfach daran gewöhnen journalctl.
glaube nicht, dass etwas schief gelaufen ist, trotzdem würde ich gerne deine Antwort annehmen, wenn du Vorschläge zur Lösung meines Problems hinzufügen
könntest
Es wurde versucht, den Syslog-Daemon manuell so zu konfigurieren, dass nach dem Lernprogramm die Startprotokolldatei generiert wird. Ich habe # Save boot messages auch zu boot.log local7 hinzugefügt. * /Var/log/boot.log zu meiner /etc/rsyslog.d/50-default.conf Datei no luck, /var/log/boot.log ist immer noch 22.04.2016
Jasmin
Bei meiner Neuinstallation von Ubuntu 16.04 habe ich auch festgestellt, dass sich die boot.logDatei nicht am üblichen Speicherort befindet.
@ParanoidPanda: Auf beiden genannten Rechnern habe ich eine saubere / frische Installation (kein Upgrade) von Ubuntu 16.04 LTS durchgeführt - anscheinend wird die bisherige Art der Boot-Protokollierung nicht mehr richtig unterstützt. :)
cl-netbox
1
journalctl zeigt nicht, was ich beim Booten im Splash sehe, und das brauche ich
systemd-analyze blame
und / odersystemd-analyze critical-chain
. Ich finde das einfacher, als durch Protokolldateien zu graben, um herauszufinden, was ein Problem verursacht.Antworten:
Verwenden
journalctl
Da
journald
alle Protokolle enthalten sind, können Sie denjournalctl
Befehl mit geeigneten Filtern verwenden. In dem Fall vonboot.log
, der früher Nachrichten aus dem Init-System enthielt, können Sie Folgendes tun:-b0
Zeigt Meldungen vom aktuellen Start,-b1
vom vorherigen Start usw. an. Ohne diese-b
Optionjournalctl
werden Meldungen vom Beginn des Protokolls angezeigt.SYSLOG_PID
filtert Nachrichten von PID 1, aka init.Oder:
_COMM=systemd
sucht nach Nachrichten aus demsystemd
Befehl. Dasystemd
es sich um init handelt, ist dies derjenige, an dem wir interessiert sind.--system
Filtert Nachrichten aus dem Systemprotokoll anstelle von Benutzersitzungsprotokollen.Beispiel:
journalctl
Öffnet die Protokolle standardmäßig in einem Pager, sodass Sie nicht weiterleiten müssenless
.Permanente Protokollierung
Ubuntu aktiviert standardmäßig keine persistenten Journald-Protokolle. Dank des Kommentars von @Auspex müssen Sie eine der folgenden Aktionen ausführen :
Bearbeiten
/etc/systemd/journald.conf
, um Folgendes einzuschließen:Erstellen Sie ein
/var/log/journal
Verzeichnis manuell:Verbunden:
quelle
journalctl -bX
ist dafür nutzlos, id enthält keine Meldungen, die während des Bootvorgangs wirklich auf dem Bildschirm erscheinen, nur boot.log und es funktioniert nur manchmal am 16.04. Die einzige Möglichkeit ist, ein Foto aufzunehmen oder es aufzuschreiben. Ich habe das gleiche Problem.Ich habe einige Fehlerberichte durchgesehen und dabei festgestellt: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771, dass Plymouth tatsächlich in boot.log schreibt.
Wenn Sie https://launchpadlibrarian.net/257898272/plymouth-debug.log aufrufen und in Ihrem Browser nach "boot.log" suchen, erhalten Sie die folgenden Zeilen:
Ich habe keine Ahnung, wie die Interna von Plymouth funktionieren, aber da es für den Begrüßungsbildschirm verantwortlich ist, der vor dem Anmeldebildschirm angezeigt wird, kann ich nur davon ausgehen, dass es keinen Begrüßungsbildschirm (schwarzen Bildschirm) gibt, bevor ich zum Anmeldebildschirm komme wird die Datei nicht verändert. Wenn vor dem Anmeldebildschirm ein Begrüßungsbildschirm angezeigt wird, wird die Ausgabe des Startvorgangs in die Datei boot.log umgeleitet.
quelle
GRUB_CMDLINE_LINUX_DEFAULT=""
in/etc/default/grub
alsboot.log
nicht geschrieben wird. Bei der VerwendungGRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
alsboot.log
wieder geschrieben. Ich benutze Ubuntu 19.04.In Ubuntu 16.04 befindet sich die
boot.log
Datei immer noch im/var/log
Ordner, wie Sie hier sehen können . Das Boot-Logfile ist von heute (29.04.2016). Möglicherweise ist ein Fehler aufgetreten, als Sie Ubuntu 16.04 installiert oder das Betriebssystem von Ubuntu 15.10 auf Ubuntu 16.04 LTS aktualisiert haben.Alternativ können Sie das allgemeine Startverhalten anhand der umfangreichen
kern.log
Datei untersuchen. Eine andere mögliche Alternative wäre, den Syslog-Daemon manuell zu konfigurieren , um die Boot-Protokolldatei zu generieren. Hier ist ein Tutorial, wie dies genau gemacht wird: So zeigen Sie Linux-Protokolle an und konfigurieren sieZusätzliche Information :
Ich habe das Verhalten der Startprotokollierung auf zwei verschiedenen Computern untersucht. Auf einem Computer mit einem UEFI-basierten BIOS ist die
boot.log
Datei vorhanden. Auf einem Computer mit einem älteren BIOS scheint sie jedoch überhaupt nicht zu existieren. Wenn das System also im alten BIOS-Modus (MBR / msdos) installiert ist, kann dies die Erklärung dafür sein, warum Ihreboot.log
Datei vom 22.04.2016 stammt und ein Überbleibsel von Ubuntu 15.10 ist.Aktualisierte Informationen 2016-05-02:
Ich habe das Verhalten der Boot-Protokolldatei weiter untersucht und festgestellt, dass die
boot.log
Datei noch auf dem UEFI-basierten Computer vorhanden ist, aber seit einigen Tagen ist die Datei leer. Eine andere Alternative, die ich versucht habe, um zu sehen, was während des Startvorgangs passiert, war die Installation von BootChart , die aber nach dem Neustart des Systemsbootchart.png
nicht/var/log
wie erwartet im Ordner vorhanden war. Es gab nur einen leeren/var/log/bootchart
Ordner, der auch die erwartetebootchart.png
Datei nicht enthielt .Aktualisierte Informationen 2016-05-04:
Heute
boot.log
schien die Datei wieder "Funktionalität" zu haben, sie ist mit Teilinformationen aus dem Bootvorgang gefüllt. Es scheint ein zufällig wechselndes Verhalten zu sein, das meines Erachtens auf Ask Ubuntu nicht gelöst werden kann. Sie sollten daher in Betracht ziehen, einen Fehlerbericht auf Launchpad einzureichen, um dieses Problem zu beheben.Fazit - nach einer Woche Untersuchung des
boot.log
Dateiverhaltens in Ubuntu 16.04: Sie sollten sich keine Gedanken/var/log/boot.log
mehr machen und sich einfach daran gewöhnenjournalctl
.quelle
boot.log
Datei nicht am üblichen Speicherort befindet.