如何在 Ubuntu 16.04+ 重新启动后找到以前的启动日志？

Question

我的问题是，如何从以前的系统启动尝试中找到启动日志？

今天第一次打开我的电脑时，启动过程在 Ubuntu 标志上停止，当我按下时，Esc我看到几行包含一些内核错误并在底部需要重新启动，所以我按下了Ctrl+ ALt+ Del，下次启动没有问题。

在第一次启动失败时，我无法从屏幕上找到消息。我应该给我的手机拍照吗？

/var/log/boot那里是空的，我在kern.log和syslog 中搜索了我记得今天日期的字符串，error但没有发现我在以前的启动屏幕上看到的内容熟悉的内容。

$ journalctl -b -1 在启动期间只给我内核消息，我也可以在其他地方找到，并且它们不是启动期间出现在屏幕上的内容，journalctl 对我来说没用，我正在寻找启动期间出现在屏幕上的消息。

目前，唯一的选择是拍一张在纸上写下信息的照片。

Answer 1

报告为一个错误，这是一个未记录的功能

有一个关于这个主题的错误报告。因为rsyslog已经在/var/log/syslogand syslog.1、.2.gz、.3.gz... 中维护了多个引导日志，syslog.7.gz所以开发人员认为保留额外的journalctl日志会浪费磁盘空间。

错误报告在2018年1 月 3 日指出，新安装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 手册页：

存储=

控制存储日志数据的位置。“volatile”、“persistent”、“auto”和“none”之一。如果“易失”，日志日志数据将仅存储在内存中，即低于 /run/log/journal 层次结构（如果需要创建）。如果“持久”，则数据将优先存储在磁盘上，即低于/var/log/journal层次结构（如果需要/run/log/journal创建），在早期启动期间以及如果磁盘不可写，则回退到（如果需要创建）。“auto”类似于“persistent”，但/var/log/journal 如果需要，不会创建目录，因此它的存在控制了日志数据的去向。“none”关闭所有存储，所有收到的日志数据都将被删除。转发到其他目标，例如控制台，但是，内核日志缓冲区或系统日志套接字仍然可以工作。默认为“自动”。

简而言之，删除注释并将该行修改为：

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=”添加匹配项。

该参数可能为空，在这种情况下，将显示当前启动的日志。

如果省略引导 ID，正偏移量将从日志的开头开始查找引导，而等于或小于零的偏移量将从日志的末尾开始查找引导。因此，1 表示按时间顺序在日志中找到的第一次引导，2 表示第二次，依此类推；-0 是最后一次启动，-1 是最后一次启动，依此类推。空偏移量等同于指定 -0，除非当前引导不是最后一次引导（例如，因为 --directory 被指定为查看来自不同机器的日志）。

然后每隔一段时间，您可以使用cron或计时器清理旧日志：

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

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

Answer 2

使用journalctl -bX其中 x 是您引用的启动，也是-b0您的实际启动和-b-1之前的启动（仅当您存在/var/log/journal属于“systemd-journal”组的文件夹时才有效）。不能告诉你到底能走多远，但那两个是肯定的。

列出可用的靴子

journalctl --list-boots

Answer 3

我遇到了同样的问题，显然在#ubuntuirc-channel上找到了答案。

无论出于何种原因，我都缺少/var/log/journal systemd-journal 可访问的文件夹组。

添加文件夹后，我可以通过以下方式查看以前启动的日志 $ journalctl -b1

Answer 4

从 systemd-journald 的手册页中的最佳答案中完成解决方案的步骤：

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

我是这样做的