Я помітив, що мій /var/log/boot.logфайл має дату 2016-04-22, востаннє завантажувався в 15.10. Де розміщені boot.logфайли Xenial ?

Використовуйте journalctl

Оскільки journaldмістяться всі журнали, ви можете використовувати journalctlкоманду з відповідними фільтрами. У випадку boot.log, який раніше містив повідомлення з системи init, ви можете зробити:

journalctl -b0 SYSLOG_PID=1

• -b0показує повідомлення з поточного завантаження, -b1з попереднього завантаження тощо. Без -bопції, journalctlбуде показано повідомлення з початку журналу.
• SYSLOG_PID фільтрує повідомлення з PID 1, aka init.

Або:

journalctl -b0 --system _COMM=systemd

• _COMM=systemdшукає повідомлення з systemdкоманди. Оскільки systemdце init, то нас це цікавить.
• --system фільтрує повідомлення з системного журналу замість журналів сеансів користувача.

Приклад:

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відкриває журнали в пейджері за замовчуванням, тому вам не потрібно передавати less.

Стійкі лісозаготівлі

За замовчуванням Ubuntu не вмикає стійкі журнали журналу. Завдяки коментарю @Auspex , вам потрібно зробити що-небудь з:

1. Змінити, /etc/systemd/journald.confщоб включити:

   Storage=persistent
   

2. Створіть /var/log/journalкаталог вручну:

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

Пов'язані:

• Як відображати повідомлення журналу з попередніх завантажувальних програм під CentOS 7?

Я переглядав кілька звітів про помилки і помічав у цьому: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771, що Plymouth насправді пише в boot.log.

Якщо ви подивитесь на https://launchpadlibrarian.net/257898272/plymouth-debug.log та шукаєте у своєму браузері "boot.log", ви отримаєте наступні рядки:

[main.c:821] on_system_initialized:system now initialized, opening log 
[main.c:742] get_log_file_for_state:returning log file '/var/log/boot.log'
[main.c:805] prepare_logging:opening log '/var/log/boot.log'

Я не розумію, як працює внутрішній апарат Plymouth, але оскільки він відповідає за екран сплеску, який відображається перед екраном входу, я можу тільки припустити, що якщо немає екрана сплеску (чорний екран), перш ніж потрапити на екран входу , файл не змінено. Якщо у вас є екран заставки, що відображається перед екраном входу, вихідний процес завантаження буде переспрямований у файл boot.log.

У Ubuntu 16.04 boot.logфайл все ще знаходиться в /var/logпапці, як ви можете бачити тут . Файл завантаження розпочато з сьогоднішнього дня (2016-04-29). Можливо, щось пішло не так, коли ви встановили Ubuntu 16.04 або оновили операційну систему з Ubuntu 15.10 до Ubuntu 16.04 LTS.

Крім того, ви можете вивчити загальну поведінку завантаження з вичерпного kern.logфайлу. Інша можлива альтернатива - це вручну налаштувати демона syslog для створення файлу журналу завантаження, і ось підручник, як саме це зробити: Як переглянути та налаштувати журнали Linux

Додаткова інформація :

Я досліджував поведінку журналу завантаження на двох різних машинах. На комп’ютері з BIOS на базі UEFI boot.logфайл існує - але на комп'ютері зі застарілим BIOS, здається, він взагалі не існує. Так що, якщо система встановлена ​​у застарілому режимі BIOS (MBR / msdos), це може бути поясненням того, чому ваш boot.logфайл датований 2016-04-22, це залишок від Ubuntu 15.10.

Оновлена ​​інформація 2016-05-02:

Я продовжував досліджувати поведінку файлу реєстрації завантаження та зауважив, що boot.logфайл все ще існує на машині, що базується на UEFI, але через кілька днів файл порожній. Ще одна альтернатива, яку я намагався побачити, що відбувається під час завантажувального процесу, полягав у встановленні BootChart , але bootchart.pngне існував у /var/logпапці, як очікувалося після перезавантаження системи ... була лише порожня /var/log/bootchartпапка, яка також не містила очікуваного bootchart.pngфайлу.

Оновлена ​​інформація 2016-05-04:

Сьогодні boot.logфайл, здавалося, знову має "функціональність", він заповнений частковою інформацією з процесу завантаження. Здається, що поведінка, що змінюється випадковим чином, я думаю, що тут не можна вирішити питання на Ask Ubuntu - тому вам слід розглянути можливість подати звіт про помилки на Launchpad, щоб вирішити це!

Висновок - після тижня дослідження boot.logповедінки файлів в Ubuntu 16.04: Ви більше не повинні турбуватися /var/log/boot.logі просто звикаєте до journalctlцього.