自16.04以来没有更多的启动日志记录？
我注意到我的/var/log/boot.log文件的日期是2016-04-22，上次我是在15.10启动的。 Xenial boot.log文件位于何处？
使用journalctl
由于journald包含所有日志，因此您可以将journalctl命令与适当的filter一起使用。 对于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 . 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默认情况下会在分页journalctl打开日志，因此您无需管道less 。
持久记录
默认情况下，Ubuntu不启用持久性日志日志。 感谢@Auspex的评论 ，您需要执行以下任一操作：
-
编辑
/etc/systemd/journald.conf以包含：Storage=persistent -
手动创建
/var/log/journal目录：mkdir /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald
有关：
- 如何在CentOS 7下显示以前引导的日志消息？
在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 ，但重启系统后， /var/log文件夹中没有按预期存在bootchart.png …只有一个空/var/log/bootchart文件夹，它也不包含预期的bootchart.png文件。
更新信息2016-05-04：
今天boot.log文件似乎再次具有“function”，它充满了启动过程中的部分信息。 它似乎是一个随机变化的行为，我认为这不能在Ask Ubuntu上解决 – 所以你应该考虑在Launchpad上提交bug报告来解决这个问题！
结论 – 在对Ubuntu 16.04中的boot.log文件行为进行一周调查之后：您不应再担心/var/log/boot.log而只是习惯于使用journalctl 。
我正在浏览一些错误报告并注意到这一点： 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文件。