System log in linux reboot

How to find previous boot log after Ubuntu 16.04+ restarts?

My question is, how can I find boot log from previous system boot attempt? Today when first powering on my PC, boot process stopped on Ubuntu logo, when I pressed Esc I have seen several lines containing some kernel error and restart required at the bottom, so I pressed Ctrl + ALt + Del and next boot went OK without problems. I have trouble finding messages from the screen I have seen during the first unsuccessful boot. Should I have taken picture to my phone? /var/log/boot is there but empty, I searched kern.log and syslog for strings I remembered with today’s date like error but found nothing familiar to what I have seen on previous boot screen. $ journalctl -b -1 gives me only kernel messages during boot, I can find that elsewhere too, and they are not what was appearing on screen during boot, journalctl is useless for me, I am looking for messages appearing on screen during boot time. For now, only option is take a photo of write the message on paper.

5 Answers 5

Reported as a bug that’s an undocumented feature

There is a bug report filed on this topic. Because rsyslog already maintains multiple boot journals in /var/log/syslog and syslog.1 , .2.gz , .3.gz . syslog.7.gz the developers felt keeping extra journalctl logs would waste disk space.

The bug report states on January 3, 2018 that for new installs rsyslog will no longer be the default and that journalctl will keep multiple boot data logs.

Create multiple boot logs without reinstalling Ubuntu

Most of us won’t do a new install so to enable multiple journalctl boot logs in which case we can use:

$ 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 

According to this github report the warning message «Cannot set file attribute» can be ignored.

Optional persistent storage setting

After using previous boot logging for many months I’ve discovered another option that can be set in /etc/systemd/journald.conf :

Storage=

Controls where to store journal data. One of «volatile», «persistent», «auto» and «none». If «volatile», journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If «persistent», data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. «auto» is similar to «persistent» but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. «none» turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to «auto».

In a nutshell remove the comment and revise the line to:

Display list of previous boots

$ 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 

Display last boot log

$ 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 

Pay close attention to the parameter -b-1 it is different than other references you may see. From man page:

journalctl --vacuum-time=2d # keep last two days or journalctl --vacuum-size=300M # keep last 300MB 

Источник

How to configure your system to preserve system logs after a reboot

Log entries for the systemd-journald service, which is at the heart of the logging architecture in Red Hat Enterprise Linux (RHEL), do not persist across reboots.

This means entries are wiped after a reboot, so you won’t have historical data for analysis. However, with a little configuration, you can keep log entries even after a reboot.

Keep system journals after a reboot

The process involves creating a storage location (probably in /var/log ) and then editing the journald configuration to direct messages to that location.

Create a storage directory

First, create a journal directory under the /var/log directory:

[server]$ sudo mkdir /var/log/journal

Edit the journald.conf file

Edit the file /etc/systemd/journald.conf and set the Storage parameter to persistent (it is set to auto by default):

[server]$ sudo vim /etc/systemd/journald.conf [Journal] Storage=persistent [. ]

[ How are your text editor skills? Read up on Vim and Nano competencies to find out. ]

Restart systemd-journald

Next, restart the systemd-journald service:

[server]$ systemctl restart systemd-journald

Reboot the server

Finally, reboot the server to confirm the persistence of entries by listing the /var/log/journal content. You should have output that looks similar to this:

[server]$ ls /var/log/journal 75ab164a278e48be9cf80d80716a8cd9

Wrap up

The logging capabilities of systemd-journald are critical, but the default configuration does not preserve these logs. Having data to analyze is vital when troubleshooting or profiling your system. Use this simple configuration to keep your system journals for as long as you need them.

Источник

How to view all boot messages in Linux after booting?

Is there a straightforward way to achieve either of these?

CONFIG_BOOT_PRINTK_DELAY: Delay each boot printk message by N milliseconds

Strangely I don’t seem allowed to even select BOOT_PRINTK_DELAY in my menuconfig, I can find it when searching for it, but under Kernel hacking -> printk and dmesg options ->, I only have «Show timing information on printks» and «Default message log level». Where is the printk delay option? Do I need to enable something else first to make it visible? What? It would be nice to have this as part of an answer, if anyone knows.

But anyway this requires a kernel recompilation which makes this an ugly and invasive hack for a seemingly trivial task. A proper way of doing this would be very much welcome.

Well dmesg is the location of that file. If it doesn’t exist on boot it will be created so if you want make your startup include a line in the init.d which moves it to another file. I’m sure you could reuse the command set that does the standard log rotation for that file then you could keep the last N iterations. The only messages you won’t see would cause grub to fail to boot and if that’s the case you won’t have a huge pile of text scrolling onto the screen.

If instead you were trying to capture the text prior to the BIOS passing control to the hard drive boot sector you would have to have some sort of screen capture utility over a Serial management port or ipmi. Both of which require server-class hardware.

4 Answers 4

So your console has two types of messages:

Kernel messages are always stored in the kmsg buffer, visible via dmesg . They’re also often copied to your syslog. (This also applies to userspace messages written to /dev/kmsg , but those are fairly rare.)

Meanwhile, when userspace writes its fancy boot status text to /dev/console or /dev/tty1 , it’s not stored anywhere at all. It just goes to the screen and that’s it. So I think pretty much any solution – except for Rowan’s serial console suggestion – will end up being either very distro-specific (due to each init system performing logging differently) or an «invasive hack» that involves strace or kernel hacking or such.

In the best case, your init system will itself log all important events to the syslog (/var/log/messages or such). For example:

systemd[1]: Starting BIRD routing daemon. bird[478296]: /etc/bird.conf, line 2: syntax error systemd[1]: bird.service: Control process exited, code=exited status=1 systemd[1]: Failed to start BIRD routing daemon. 

(systemd and upstart also log the services’ stdout/stderr as well; many other init systems just redirect it to the console or nowhere.)

As grub boots before the kernel perhaps it can leave a listener on /dev/tty1? Some sort of low level screen recorder.

One suggestion is to have another laptop film the boot screen with high resolution and frame rates then slow play the resulting (MOV — MP4 — AVI) — maybe not the best solution but simply to deploy and its for debugging anyway right ? Just an Idea .

Grawity’s answer is must better described than I would have been able to accomplish for that stage in the boot.

On the physical redirection method, your BIOS has to support it. Server geared boards usually do. The Intel, IBM, and SuperMicro systems typically have a Console Redirection option under the main heading of the BIOS. It cannot be used if your motherboard does not have a physical serial port, e.g. only USB. You may need to attach a physical port to pins on the motherboard if it has it.

Console Redirection can cause wackiness when you get to the point where the operating system is trying to use the serial port for something else. I would say it’s primarily used for debugging in a particular case rather than constant use.

To use, you would need to set matching port settings on your receiver com port which could be usb based, then you need to link the two devices with a null modem cable which exchanges the transmit and receive pins between the devices.

The receiving device needs to be fully powered on and watching for the communication during the boot of the source system. The receiving system will get all text based output.

If during boot your OS starts displaying text via a grapical construct rather than as text, the receiving system will get gibberish.

Источник