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

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

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

我无法从第一次不成功启动时看到的屏幕中查找消息。我应该把照片拍到手机上吗？

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

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

目前，只有选项是在纸上写下留言的照片。

报告为一个没有文档记录的bug

有关此主题的错误报告。由于rsyslog已在/var/log/syslog和syslog.1 ， .2.gz ， .3.gz … syslog.7.gz维护了多个启动/var/log/syslog ，因此开发人员认为保留额外的日志日志会浪费磁盘空间。

错误报告指出，2018年1月3日 ，对于新安装， journalctl将不再是默认设置，并且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设置的选项：

存储=

控制存储日记数据的位置。其中一个是“易变”，“持久”，“自动”和“无”。如果是“volatile”，则日志日志数据将仅存储在内存中，即低于/ run / log / journal层次结构（如果需要，则创建）。如果“持久”，数据将优先存储在磁盘上，即在/var/log/journal层次结构（在需要时创建）之下，并且回退到/run/log/journal （如果需要，则创建），期间早期启动，如果磁盘不可写。 “auto”类似于“persistent”，但是如果需要，不会创建目录/var/log/journal ，因此它的存在控制着日志数据的去向。 “none”关闭所有存储，所有收到的日志数据都将被删除。转发到其他目标（例如控制台，内核日志缓冲区或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 Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reser Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usabl Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reser Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000030a5ffff] usabl Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a60000-0x0000000030a71fff] reser Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a72000-0x0000000030a89fff] usabl Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8a000-0x0000000030a8afff] ACPI Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8b000-0x0000000030ad4fff] reser Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030ad5000-0x0000000030b2dfff] usabl Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030b2e000-0x0000000031099fff] reser lines 1-29

密切关注参数-b-1它与您可能看到的其他参考文献不同。

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

出于任何原因，我错过了systemd-journal可访问的文件夹/var/log/journal组。

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

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

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

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

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

使用journalctl -bX ，其中x是你引用的引导，所以-b0是你的实际引导， -b1是引导之前（仅当你有属于’systemd-journal’组的文件夹/var/log/journal时才有效））。不能告诉你到底能走多远，但这两个肯定。

从这里的顶部答案来完成解决方案的步骤，来自systemd-journald的手册页：

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

我这样做是为了su