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

今天，当第一次打开计算机电源时，启动过程在Ubuntu徽标上停止了，当我按下时，Esc我看到几行包含一些内核错误，并且需要在底部重新启动，因此我按下Ctrl+ ALt+ Del，下一次启动就可以了，没有问题。

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

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

$ journalctl -b -1 在引导过程中仅给我提供内核消息，我也可以在其他地方找到它们，它们也不是引导过程中在屏幕上显示的内容，Journalctl对我来说毫无用处，我正在寻找引导时间在屏幕上显示的消息。

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

报告为未记录功能的错误

有关此主题的错误报告已提交。因为rsyslog已经在/var/log/syslog和syslog.1，...中维护了多个启动日志.2.gz，所以开发人员感到保留额外的日志会浪费磁盘空间。.3.gzsyslog.7.gzjournalctl

错误报告指出，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”，则日记日志数据将仅存储在内存中，即/ run / log / journal层次结构（如果需要，则在其下面）中。如果为“永久”，则数据将优选存储在磁盘上，即在/var/log/journal层次结构下（如果需要创建，则在层次结构下），回退到/run/log/journal（如果需要则创建），在早期引导期间以及磁盘不可写时。“ auto”类似于“ persistent”，但是在/var/log/journal 需要时不会创建目录，因此该目录的存在控制着日志数据的去向。“无”关闭所有存储，所有接收到的日志数据将被删除。转发到其他目标，例如控制台，内核日志缓冲区或syslog套接字仍然可以使用。默认为“自动”。

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

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

我遇到了同样的问题，并且显然在#ubuntuirc频道上找到了答案。

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

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

从最高答案（此处为systemd-journald的手册页）中完成解决方案的步骤：

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

我这样做是为了

答案可以在中找到man journald.conf，特别是选项Storage=：

控制日记数据的存储位置。“易失性”，“持久性”，“自动”和“无”之一。[...]“ auto”类似于“ persistent”，但是如果需要，则不创建目录/ var / log / journal，因此它的存在控制着日志数据的去向。[...]默认为“自动”。

请记住，不需要日志轮换或旧syslog守护程序常用的类似技术。默认情况下，日志文件配置为增长到一定大小，并且当日志文件太大时，旧的日志条目会自动删除。

在我的系统上，此大小当前配置为120MB，您可以/etc/systemd/journald.conf为systemd-journald.service单元进行调整。

使用journalctl -bXx是您所指的引导，-b0实际引导和-b-1之前引导也是如此（仅当您拥有/var/log/journal属于组'systemd-journal' 的文件夹时，该引导才起作用）。不能告诉您可以走多远，但是可以肯定的是那两个。

列出可用的靴子

journalctl --list-boots