我注意到我的/var/log/boot.log文件的日期为2016-04-22，这是我上一次在15.10中启动。Xenial boot.log文件在哪里？

使用 journalctl

由于journald包含所有日志，因此可以将journalctl命令与适当的过滤器一起使用。对于boot.log，它曾经包含来自init系统的消息，您可以执行以下操作：

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日志

附加信息 ：

我调查了两台不同计算机上的引导日志记录行为。在具有基于UEFI的BIOS的计算机上，该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 Ask Ubuntu上无法解决-因此您应该考虑在Launchpad上提交错误报告以解决此问题！

结论 -在boot.log对Ubuntu 16.04 中的文件行为进行了一周的调查之后：您不必再担心了/var/log/boot.log，journalctl而习惯了。