Я заметил, что мой /var/log/boot.logфайл имеет дату 2016-04-22, последний раз я загружался в 15.10. Где находятся boot.logфайлы Xenial ?

использование journalctl

Поскольку journaldсодержит все журналы, вы можете использовать journalctlкоманду с подходящими фильтрами. В случае boot.log, который раньше содержал сообщения от системы инициализации, вы могли бы сделать:

journalctl -b0 SYSLOG_PID=1

• -b0показывает сообщения от текущей загрузки, -b1от предыдущей загрузки и так далее. Без -bопции journalctlбудут показываться сообщения с начала журнала.
• SYSLOG_PID фильтрует сообщения из PID 1, он же 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, что Плимут на самом деле пишет в 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.