Benim sorum, önceki sistem önyükleme girişiminden önyükleme günlüğünü nasıl bulabilirim?

Bugün bilgisayarımı ilk açtığımda, Ubuntu logosunda önyükleme işlemi durdu, bastığımda Escbazı çekirdek hataları içeren birkaç satır gördüm ve altta gerekli yeniden başlatmayı gördüm, bu yüzden Ctrl+ ALt+ tuşuna bastım Delve bir sonraki önyükleme sorunsuz gitti.

İlk başarısız önyükleme sırasında gördüğüm ekrandan mesaj bulmakta sorun yaşıyorum. Telefonuma fotoğraf çekmeliydim?

/var/log/bootvar ama boş, kern.log ve syslog'u bugünün tarihi ile hatırladığım dizeleri aradım, errorancak önceki önyükleme ekranında gördüğüm şeylere tanıdık bir şey bulamadım.

$ journalctl -b -1 bana önyükleme sırasında sadece çekirdek mesajları verir, bunu başka bir yerde de bulabilirim ve önyükleme sırasında ekranda görünen şey değiller, journalctl benim için işe yaramaz, önyükleme süresi boyunca ekranda görünen mesajları arıyorum.

Şimdilik, sadece seçenek mesajı kağıda yazmanın bir fotoğrafını çekmek.

Belgelenmemiş bir özellik olan bir hata olarak bildirildi

Bu konuda dosyalanmış bir hata raporu var . Çünkü rsyslogzaten birden önyükleme dergileri korur /var/log/syslogve syslog.1, .2.gz, .3.gz... syslog.7.gzgeliştiriciler ekstra tutarak keçe journalctldisk alanı israf olur günlükleri.

Hata raporu, 3 Ocak 2018'de yeni yüklemeler için rsyslogartık varsayılan journalctlolmayacağını ve birden çok önyükleme veri günlüğünü tutacağını belirtiyor .

Ubuntu'yu yeniden yüklemeden birden fazla önyükleme günlüğü oluşturun

Çoğumuz yeni bir yükleme yapmayacağız, bu nedenle birden fazla journalctlönyükleme günlüğünü etkinleştirmek için bu durumda kullanabiliriz:

$ 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

Bu github raporuna göre "Dosya özniteliği ayarlanamıyor" uyarı mesajı yok sayılabilir.

İsteğe bağlı kalıcı depolama ayarı

Önceki önyükleme günlüğünü aylarca kullandıktan sonra ayarlanabilecek başka bir seçenek keşfettim/etc/systemd/journald.conf :

Gönderen journald.conf adam sayfası :

Depolama =

Günlük verilerinin nerede depolanacağını denetler. "Uçucu", "kalıcı", "otomatik" ve "yok" tan biri. "Geçici" ise, günlük günlüğü verileri yalnızca bellekte, yani / run / log / günlük hiyerarşisinin altında saklanır (gerekirse oluşturulur). "Kalıcı" ise, veriler tercihen diskte, yani /var/log/journalhiyerarşinin altında (gerekirse oluşturulur), bir /run/log/journalönyükleme (gerekirse oluşturulur), erken önyükleme sırasında ve disk yazılabilir değilse saklanır. "auto", "sürekli" ile benzerdir, ancak gerekirse dizin /var/log/journal oluşturulmaz, böylece varlığı günlük verilerinin nereye gittiğini denetler. "none" tüm depolama alanını kapatır, alınan tüm günlük verileri kaldırılır. Konsol gibi diğer hedeflere yönlendirme, ancak çekirdek günlük arabelleği veya bir syslog soketi yine de çalışır. Varsayılan olarak "otomatik".

Özetle yorumu kaldırın ve satırı şu şekilde değiştirin:

Storage=persistent

Önceki botların listesini görüntüle

$ 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

Son önyükleme günlüğünü görüntüle

$ 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

Görebileceğiniz -b-1diğer referanslardan farklı olan parametreye çok dikkat edin . Gönderen adam sayfası :

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

Belirli bir önyüklemedeki mesajları göster. Bu, "_BOOT_ID =" için bir eşleşme ekleyecektir.

Bağımsız değişken boş olabilir, bu durumda geçerli önyükleme için günlükler gösterilir.

Önyükleme kimliği atlanırsa, günlükün başından başlayarak pozitif bir kayma botları arar ve derginin sonundan başlayarak sıfırdan küçük veya eşit bir kayma botları arar. Böylece, 1 dergide kronolojik sırada bulunan ilk önyükleme, 2 ikincisi vb. Anlamına gelir; -0 ise son önyükleme, sondan önceki önyükleme -1, vb. Boş bir ofset, geçerli önyüklemenin son önyükleme olmadığı durumlar dışında -0 belirtilmesine eşdeğerdir (örneğin, --dizini, farklı bir makinedeki günlüklere bakmak için belirtildiğinden).

Daha sonra arada bir, cronveya zamanlayıcılarla eski günlükleri temizleyebilirsiniz :

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

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

Aynı sorunu yaşadım ve görünüşe göre #ubuntuirc kanalında cevabı buldum .

Herhangi bir nedenle, /var/log/journal systemd-journal tarafından erişilebilen klasör grubunu kaçırıyordum .

Klasörü ekledikten sonra, önceki botların günlüklerini $ journalctl -b1

Çözümü burada en üstteki yanıttan, systemd-dergi için man sayfasından gerçekleştirme adımları:

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

Bunu su olarak yaptım

Cevap man journald.conf, özellikle seçenekte bulunabilir Storage=:

Günlük verilerinin nerede depolanacağını denetler. "Uçucu", "kalıcı", "otomatik" ve "yok" tan biri. [...] "auto", "sürekli" ye benzer, ancak gerekirse / var / log / journal dizini oluşturulmaz, böylece varlığı günlük verilerinin nereye gittiğini kontrol eder. [...] Varsayılan olarak "otomatik".

Lütfen eski syslog arka plan programında ortak olan günlük rotasyonuna veya benzer tekniklere gerek olmadığını unutmayın. Günlük dosyası varsayılan olarak belirli bir boyuta büyüyecek şekilde yapılandırılmıştır ve günlük dosyası çok büyüdüğünde eski günlük girişleri otomatik olarak silinir.

Sistemimde bu boyut şu anda /etc/systemd/journald.conf120MB olarak yapılandırılmış , systemd-journalald.service birimi için ayarlayabilirsiniz .

journalctl -bXX'in başvurduğunuz önyükleme olduğu yerde kullanın -b0, gerçek önyüklemeniz ve -b-1önceki önyüklemeniz de (bu yalnızca /var/log/journal'systemd-journal' grubuna ait klasörünüz varsa çalışır ) kullanın. Tam olarak ne kadar ileri gidebileceğinizi söyleyemem ama bu ikisi kesin.

Mevcut botları listele

journalctl --list-boots