Моє запитання: як я можу знайти журнал завантаження з попередньої спроби завантаження системи?

Сьогодні при першому включенні мого ПК процес завантаження зупинився на логотипі Ubuntu, коли я натиснув, Escя побачив декілька рядків, що містять певну помилку ядра та потрібно перезапустити внизу, тому я натиснув Ctrl+ ALt+ Delі наступне завантаження пішло нормально без проблем.

У мене проблеми з пошуку повідомлень з екрана, які я бачив під час першого невдалого завантаження. Чи повинен я сфотографуватися на своєму телефоні?

/var/log/bootє, але порожній, я шукав рядки kern.log та syslog, які я пам’ятав із сьогоднішньою датою, як-от, errorале не знайшов нічого знайомого з тим, що я бачив на попередньому екрані завантаження.

$ journalctl -b -1 дає мені лише повідомлення ядра під час завантаження, я можу виявити, що і в іншому місці, і вони не є тим, що з'являлося на екрані під час завантаження, journalctl для мене марний, я шукаю повідомлення, що з’являються на екрані під час завантаження.

Поки що єдиний варіант - сфотографувати написання повідомлення на папері.

Повідомляється як про помилку, яка є недокументованою функцією

На цю тему подано звіт про помилки . Оскільки rsyslogвже підтримує кілька журналів завантаження в /var/log/syslogі syslog.1, .2.gz, .3.gz... syslog.7.gzрозробники вважали , зберігаючи додаткові journalctlжурнали будуть витрачати дисковий простір.

Звіт про помилку зазначає 3 січня 2018 року, що для нових встановлень rsyslogбільше не буде типовим і що journalctlвін зберігатиме кілька журналів даних завантаження.

Створіть кілька журналів завантаження без перевстановлення Ubuntu

Більшість з нас не буде робити нову установку, щоб увімкнути кілька journalctlжурналів завантаження, і в цьому випадку ми можемо використовувати:

$ 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

Відповідно до цього звіту github попереджувальне повідомлення "Неможливо встановити атрибут файлу" можна ігнорувати.

Необов’язкові стійкі настройки зберігання

Після використання попереднього журналу завантаження протягом багатьох місяців я виявив ще один варіант, який можна встановити /etc/systemd/journald.conf:

З чоловічої сторінки journald.conf :

Зберігання =

Контролює, де зберігати дані журналу. Один з "непостійних", "стійких", "авто" та "жодних". Якщо "мінливі", дані журналу журналу зберігатимуться лише в пам'яті, тобто нижче ієрархії / run / log / journal (яка створюється за потреби). Якщо "стійкий", дані зберігатимуться бажано на диску, тобто нижче /var/log/journalієрархії (яка створюється у разі потреби), із запасом до /run/log/journal(який створюється за потреби), під час раннього завантаження та якщо диск не піддається запису. "auto" схожий на "persistent", але каталог /var/log/journal не створюється при необхідності, так що його існування контролює, куди йдуть дані журналу. "none" вимикає все сховище, усі отримані дані журналу будуть видалені. Переадресація до інших цілей, наприклад консолі, проте буфер журналу ядра або сокет syslog все ще працюватимуть. За замовчуванням встановлено "авто".

Коротше кажучи, видаліть коментар та перегляньте рядок:

Storage=persistent

Відобразити список попередніх чобіт

$ 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

Показати останній журнал завантаження

$ 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

Зверніть пильну увагу на параметр, який -b-1він відрізняється від інших посилань, які ви можете бачити. З чоловічої сторінки :

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

Показати повідомлення з певного завантаження. Це додасть відповідність для "_BOOT_ID =".

Аргумент може бути порожнім, і в цьому випадку будуть показані журнали для поточного завантаження.

Якщо ідентифікатор завантаження пропущено, позитивний зсув буде шукати черевики, починаючи з початку журналу, а рівне або менше нульового зміщення буде шукати черевики, починаючи з кінця журналу. Таким чином, 1 означає перший завантаження, знайдене в журналі в хронологічному порядку, 2 друге тощо; в той час як -0 - це остання завантаження, -1 завантаження до останнього тощо. Порожній зсув еквівалентний зазначенню -0, за винятком випадків, коли поточний завантажувач не є останнім завантаженням (наприклад, тому, що --директорія була визначена для перегляду журналів з іншої машини).

Тоді час від часу за допомогою cronта таймерів ви можете очищати старі журнали :

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

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

У мене було те саме питання, і явно я знайшов відповідь на #ubuntuirc-каналі.

З якоїсь причини мені не вистачало /var/log/journal групи папок, доступних для systemd-journal.

Після додавання папки я зміг побачити журнали попередніх черевиків через $ journalctl -b1

Етапи для вирішення рішення з головної відповіді тут, зі сторінки man для systemd-journald:

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

Я зробив це як су

Відповідь можна знайти в man journald.confконкретному варіанті Storage=:

Контролює, де зберігати дані журналу. Один з "непостійних", "стійких", "авто" та "жодних". [...] "auto" схожий на "persistent", але каталог / var / log / journal не створюється при необхідності, так що його існування контролює, куди йдуть дані журналу. [...] За замовчуванням встановлено "авто".

Будь ласка, майте на увазі, що немає необхідності в обертанні журналу або подібних техніках, які були загальними для старого демона syslog. Файл журналу за замовчуванням налаштовується на певний розмір, а старі записи журналу автоматично видаляються, коли файл журналу зростає занадто великим.

У моїй системі цей розмір наразі налаштований як 120 Мб, ви можете налаштувати його /etc/systemd/journald.confдля блоку systemd-journald.service.

Використовуйте, journalctl -bXде x - завантаження, на яке ви посилаєтесь, так само -b0є ваше фактичне завантаження та -b-1завантаження раніше (яке працює лише у тому випадку, якщо у вас є папка, /var/log/journalщо належить до групи 'systemd-journal'). Не можу сказати, як далеко ви можете піти, але ці двоє точно.

Список доступних черевиків з

journalctl --list-boots