Moje pytanie brzmi: jak znaleźć dziennik rozruchu z poprzedniej próby rozruchu systemu?

Dzisiaj, kiedy po raz pierwszy uruchomiłem komputer, proces uruchamiania zatrzymał się na logo Ubuntu, kiedy nacisnąłem Esc, zobaczyłem kilka wierszy zawierających błąd jądra i wymagane ponowne uruchomienie na dole, więc nacisnąłem Ctrl+ ALt+, Dela następne uruchomienie przebiegło bez problemów.

Mam problem ze znalezieniem wiadomości z ekranu, który widziałem podczas pierwszego nieudanego rozruchu. Czy powinienem zrobić zdjęcie na telefon?

/var/log/bootjest tam, ale jest pusty, szukałem ciągów kern.log i syslog, które zapamiętałem z dzisiejszą datą, errorale nie znalazłem nic znajomego do tego, co widziałem na poprzednim ekranie rozruchowym.

$ journalctl -b -1 daje mi tylko komunikaty jądra podczas rozruchu, mogę to również znaleźć gdzie indziej, i nie są one tym, co pojawiło się na ekranie podczas uruchamiania, Journalctl jest dla mnie bezużyteczny, szukam komunikatów pojawiających się na ekranie podczas uruchamiania.

Na razie jedyną opcją jest zrobienie zdjęcia z napisem wiadomości na papierze.

Zgłoszony jako błąd będący funkcją nieudokumentowaną

Zgłoszono błąd w tym temacie . Bo rsyslogjuż utrzymuje wiele czasopism startowych w /var/log/syslogi syslog.1, .2.gz, .3.gz... syslog.7.gzdeweloperzy czuł utrzymanie dodatkowych journalctldzienników marnować miejsca na dysku.

Raport o błędach stwierdza 3 stycznia 2018 r., Że w przypadku nowych instalacji rsyslognie będzie już domyślny i że journalctlbędzie przechowywać wiele dzienników danych rozruchowych.

Utwórz wiele dzienników rozruchu bez ponownej instalacji Ubuntu

Większość z nas nie wykona nowej instalacji, aby włączyć wiele journalctldzienników rozruchu, w takim przypadku możemy użyć:

$ sudo mkdir -p /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal
Cannot set file attribute for '/var/log/journal', value=0x00800000, mask=0x00800000: Operation not supported

Zgodnie z tym raportem github komunikat ostrzegawczy „Nie można ustawić atrybutu pliku” można zignorować.

Opcjonalne ustawienie trwałego przechowywania

Po wielu miesiącach rejestrowania rozruchu odkryłem inną opcję, którą można ustawić /etc/systemd/journald.conf:

Ze strony podręcznika Journald.conf :

Storage =

Kontroluje, gdzie przechowywać dane dziennika. Jeden z „niestabilnych”, „trwałych”, „automatycznych” i „brak”. Jeśli jest „niestabilny”, dane dziennika będą przechowywane tylko w pamięci, tj. Poniżej hierarchii / run / log / journal (która jest tworzona w razie potrzeby). Jeśli „trwałe”, dane będą przechowywane najlepiej na dysku, tj. Poniżej /var/log/journalhierarchii (która jest tworzona w razie potrzeby), z możliwością powrotu do /run/log/journal(która jest tworzona w razie potrzeby), podczas wczesnego rozruchu i jeśli dysku nie można zapisać. „auto” jest podobne do „trwałego”, ale katalog /var/log/journal nie jest tworzony w razie potrzeby, więc jego istnienie kontroluje, dokąd trafiają dane dziennika. „none” wyłącza całą pamięć, wszystkie otrzymane dane dziennika zostaną usunięte. Przekazywanie do innych celów, takich jak konsola, bufor dziennika jądra lub gniazdo syslog będą jednak nadal działać. Domyślnie „auto”.

W skrócie usuń komentarz i popraw wiersz, aby:

Storage=persistent

Wyświetla listę poprzednich butów

$ journalctl --list-boots
-15 58a9e56135564cd8a52d547b19e76bf5 Fri 2018-02-02 18:34:35 MST—Fri 2018-02-02 23:07:14 M
-14 3514e056440341b1b6e5f03d109681bc Sat 2018-02-03 06:05:12 MST—Sat 2018-02-03 08:07:44 M
-13 0d1a32dc275348589f5ecdc72180c018 Sat 2018-02-03 08:08:05 MST—Sat 2018-02-03 08:08:34 M
-12 74159b593f3a401589ee6bd78e31684b Sat 2018-02-03 08:08:51 MST—Sun 2018-02-04 08:32:09 M
-11 4b394a9aad584ab2bfabe3b77eeed78f Sun 2018-02-04 08:32:26 MST—Mon 2018-02-05 16:54:02 M
-10 8e461ed2593c4fd896ca3b71eb3c0fba Mon 2018-02-05 16:54:34 MST—Tue 2018-02-06 03:54:30 M
 -9 ec7ba0e4dfe241c0b9c978d278fcca6d Tue 2018-02-06 03:54:47 MST—Tue 2018-02-06 16:25:02 M
 -8 b5c110267c214c38b63d0a367197d118 Tue 2018-02-06 16:25:19 MST—Thu 2018-02-08 16:49:03 M
 -7 75c3b117ac6a4de984dc3ced15edb7f8 Thu 2018-02-08 16:49:22 MST—Fri 2018-02-09 03:51:09 M
 -6 7338bd1007bc42dda5c8667eeefe1a59 Fri 2018-02-09 03:51:26 MST—Fri 2018-02-09 16:55:52 M
 -5 4b6cd0121327454ca3db035c7ed42df6 Fri 2018-02-09 16:56:09 MST—Sat 2018-02-10 07:55:14 M
 -4 0d56207f9ec0405ca3a3fd638334de2f Sat 2018-02-10 07:55:32 MST—Mon 2018-02-12 22:16:05 M
 -3 0f230cc546fd4aec8f5233e0074ab3e1 Tue 2018-02-13 03:57:20 MST—Wed 2018-02-14 22:58:56 M
 -2 c0d2c0141dd840cbab75d3c2254f8781 Wed 2018-02-14 22:59:13 MST—Sat 2018-02-17 22:46:14 M
 -1 aafb2573a6374e019a7165cb8eee74a0 Sun 2018-02-18 06:02:03 MST—Mon 2018-02-19 04:16:36 M
  0 8462f1969c6f4d61973e7e245014b846 Mon 2018-02-19 04:16:53 MST—Tue 2018-02-20 18:51:42 M

Wyświetl ostatni dziennik rozruchu

$ journalctl -b-1
-- Logs begin at Fri 2018-02-02 18:34:35 MST, end at Thu 2018-03-01 16:43:25 MST. --
Feb 28 20:03:15 alien systemd-journald[290]: Runtime journal (/run/log/journal/) is 8.0M, 
Feb 28 20:03:15 alien kernel: Linux version 4.14.23-041423-generic (kernel@kathleen) (gcc 
Feb 28 20:03:15 alien kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.14.23-041423-generi
Feb 28 20:03:15 alien kernel: KERNEL supported cpus:
Feb 28 20:03:15 alien kernel:   Intel GenuineIntel
Feb 28 20:03:15 alien kernel:   AMD AuthenticAMD
Feb 28 20:03:15 alien kernel:   Centaur CentaurHauls
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registe
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
Feb 28 20:03:15 alien kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 b
Feb 28 20:03:15 alien kernel: e820: BIOS-provided physical RAM map:
Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usabl
lines 1-19

Zwróć szczególną uwagę na parametr, -b-1który różni się od innych odniesień, które możesz zobaczyć. Ze strony podręcznika :

-b [ID][±offset], --boot=[ID][±offset]

Pokaż wiadomości z określonego rozruchu. Spowoduje to dodanie dopasowania dla „_BOOT_ID =”.

Argument może być pusty, w takim przypadku zostaną wyświetlone dzienniki bieżącego rozruchu.

Jeśli identyfikator rozruchu zostanie pominięty, przesunięcie dodatnie przeszuka buty, zaczynając od początku dziennika, a przesunięcie równe lub mniejsze niż zero przeszuka buty, zaczynając od końca dziennika. Tak więc 1 oznacza pierwszy boot znaleziony w czasopiśmie w porządku chronologicznym, 2 drugi i tak dalej; podczas gdy -0 to ostatni rozruch, -1 rozruch przed ostatnim i tak dalej. Puste przesunięcie jest równoważne określeniu -0, z wyjątkiem sytuacji, gdy bieżący rozruch nie jest ostatnim uruchomieniem (np. Ponieważ podano katalog --directory do przeglądania logów z innej maszyny).

Od czasu do czasu możesz wyczyścić stare dzienniki za pomocą cronlub timerów :

journalctl --vacuum-time=2d  # keep last two days or

journalctl --vacuum-size=300M  # keep last 300MB

Miałem ten sam problem i najwyraźniej znalazłem odpowiedź na #ubuntukanale irc.

Z jakiegokolwiek powodu brakowało mi /var/log/journal grupy folderów dostępnych dla systemd-journal.

Po dodaniu folderu mogłem zobaczyć dzienniki poprzednich rozruchów za pośrednictwem $ journalctl -b1

Kroki, które należy wykonać, aby znaleźć rozwiązanie z górnej odpowiedzi tutaj, ze strony podręcznika systemd-journald:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

Zrobiłem to jako su

Odpowiedź można znaleźć w man journald.conf, w szczególności opcja Storage=:

Kontroluje, gdzie przechowywać dane dziennika. Jeden z „niestabilnych”, „trwałych”, „automatycznych” i „brak”. [...] „auto” jest podobne do „trwałego”, ale katalog / var / log / journal nie jest tworzony w razie potrzeby, więc jego istnienie kontroluje, dokąd trafiają dane dziennika. [...] Domyślnie „auto”.

Należy pamiętać, że nie ma potrzeby rotacji dzienników ani podobnych technik, które były wspólne ze starym demonem syslog. Plik dziennika jest domyślnie skonfigurowany do powiększania do określonego rozmiaru, a stare wpisy dziennika są automatycznie usuwane, gdy plik dziennika staje się zbyt duży.

W moim systemie ten rozmiar jest obecnie skonfigurowany /etc/systemd/journald.confna 120 MB , możesz go dostosować do jednostki systemd-journald.service.

Użyj journalctl -bXgdzie x to boot, do którego się odnosisz , tak samo jak -b0twój boot i -b-1boot przed (co działa tylko wtedy, gdy masz folder /var/log/journalnależący do grupy „systemd-journal”). Nie mogę ci powiedzieć, jak daleko możesz się posunąć, ale na pewno te dwa.

Lista dostępnych butów z

journalctl --list-boots