Pertanyaan saya adalah, bagaimana saya bisa menemukan log boot dari upaya boot sistem sebelumnya?

Hari ini ketika pertama kali menyalakan PC saya, proses boot berhenti pada logo Ubuntu, ketika saya menekan Escsaya telah melihat beberapa baris yang mengandung beberapa kesalahan kernel dan restart diperlukan di bagian bawah, jadi saya menekan Ctrl+ ALt+ Deldan boot berikutnya berjalan OK tanpa masalah.

Saya mengalami kesulitan menemukan pesan dari layar yang saya lihat selama boot pertama yang gagal. Haruskah saya mengambil gambar ke ponsel saya?

/var/log/bootApakah ada tapi kosong, saya mencari string untuk kern.log dan syslog saya ingat dengan tanggal hari ini seperti errortetapi tidak menemukan apa pun yang akrab dengan apa yang saya lihat di layar boot sebelumnya.

$ journalctl -b -1 memberi saya hanya pesan kernel saat boot, saya dapat menemukan itu di tempat lain juga, dan mereka tidak apa yang muncul di layar saat boot, journalctl tidak berguna bagi saya, saya mencari pesan yang muncul di layar selama waktu boot.

Untuk saat ini, hanya opsi mengambil foto tulis pesan di atas kertas.

Dilaporkan sebagai bug yang merupakan fitur tidak berdokumen

Ada laporan bug yang diajukan tentang topik ini . Karena rsyslogsudah memelihara beberapa jurnal boot pada /var/log/syslogdan syslog.1, .2.gz, .3.gz... syslog.7.gzpara pengembang merasa menjaga ekstra journalctllog akan menyia-nyiakan ruang disk.

Laporan bug menyatakan pada 3 Januari 2018 bahwa untuk pemasangan baru rsyslogtidak lagi menjadi default dan yang journalctlakan menyimpan banyak data log boot.

Buat beberapa log boot tanpa menginstal ulang Ubuntu

Sebagian besar dari kita tidak akan melakukan instalasi baru sehingga untuk mengaktifkan beberapa journalctllog boot dalam hal ini kita dapat menggunakan:

$ 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

Menurut laporan github ini pesan peringatan "Tidak dapat mengatur atribut file" dapat diabaikan.

Pengaturan penyimpanan persisten opsional

Setelah menggunakan boot logging sebelumnya selama beberapa bulan, saya telah menemukan opsi lain yang dapat diatur di /etc/systemd/journald.conf:

Dari halaman manual journald.conf :

Penyimpanan =

Mengontrol tempat penyimpanan data jurnal. Salah satu dari "volatile", "persistent", "auto" dan "none". Jika "volatile", data jurnal jurnal akan disimpan hanya dalam memori, yaitu di bawah hierarki / run / log / jurnal (yang dibuat jika diperlukan). Jika "persisten", data akan disimpan lebih disukai di disk, yaitu di bawah /var/log/journalhierarki (yang dibuat jika diperlukan), dengan fallback ke /run/log/journal(yang dibuat jika diperlukan), selama boot awal dan jika disk tidak dapat ditulis. "auto" mirip dengan "persistent" tetapi direktori /var/log/journal tidak dibuat jika diperlukan, sehingga keberadaannya mengontrol ke mana data log masuk. "tidak ada" mematikan semua penyimpanan, semua data log yang diterima akan dihapus. Penerusan ke target lain, seperti konsol, buffer log kernel, atau soket syslog masih akan berfungsi. Default ke "otomatis".

Singkatnya hapus komentar dan perbaiki baris ke:

Storage=persistent

Tampilan daftar boot sebelumnya

$ 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

Tampilkan log boot terakhir

$ 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

Perhatikan parameter -b-1itu berbeda dari referensi lain yang mungkin Anda lihat. Dari halaman manual :

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

Tampilkan pesan dari boot tertentu. Ini akan menambahkan kecocokan untuk "_BOOT_ID =".

Argumen mungkin kosong, dalam hal ini log untuk boot saat ini akan ditampilkan.

Jika ID boot dihilangkan, offset positif akan mencari sepatu mulai dari awal jurnal, dan offset yang sama atau kurang dari nol akan mencari sepatu mulai dari akhir jurnal. Jadi, 1 berarti boot pertama yang ditemukan dalam jurnal dalam urutan kronologis, 2 boot kedua dan seterusnya; sedangkan -0 adalah boot terakhir, -1 boot sebelum terakhir, dan seterusnya. Offset kosong setara dengan menentukan -0, kecuali ketika boot saat ini bukan boot terakhir (mis. Karena --directory ditentukan untuk melihat log dari mesin yang berbeda).

Kemudian sesekali, dengan cronatau penghitung waktu Anda dapat membersihkan log lama :

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

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

Saya memiliki masalah yang sama, dan ternyata menemukan jawabannya di #ubuntuirc-channel.

Untuk alasan apa pun, saya kehilangan folder /var/log/journal yang dapat diakses oleh systemd-journal.

Setelah menambahkan folder, saya dapat melihat log dari boot sebelumnya melalui $ journalctl -b1

Langkah-langkah untuk mencapai solusi dari jawaban teratas di sini, dari halaman manual untuk systemd-journald:

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

Saya melakukan ini sebagai su

Jawabannya dapat ditemukan di man journald.conf, khususnya opsi Storage=:

Mengontrol tempat penyimpanan data jurnal. Salah satu dari "volatile", "persistent", "auto" dan "none". [...] "otomatis" mirip dengan "persisten" tetapi direktori / var / log / jurnal tidak dibuat jika diperlukan, sehingga keberadaannya mengontrol ke mana data log dimasukkan. [...] Default ke "otomatis".

Harap diingat bahwa tidak perlu untuk rotasi log atau teknik serupa yang sama dengan daemon syslog lama. File jurnal secara default dikonfigurasi untuk tumbuh ke ukuran tertentu dan entri log lama secara otomatis dihapus ketika file jurnal tumbuh terlalu besar.

Di sistem saya ukuran ini saat ini dikonfigurasikan sebagai 120MB, Anda dapat menyesuaikannya /etc/systemd/journald.confuntuk unit systemd-journald.service.

Gunakan di journalctl -bXmana x adalah boot yang Anda tuju, demikian -b0juga boot aktual Anda dan -b-1boot sebelumnya (yang hanya berfungsi jika Anda memiliki folder /var/log/journalmilik grup 'systemd-journal' sekarang). Tidak bisa memberi tahu Anda seberapa jauh tepatnya Anda bisa pergi tetapi keduanya pasti.

Daftar sepatu bot yang tersedia dengan

journalctl --list-boots