No more boot logging since 16.04?
Solution 1
I was going through some bug reports and noticed in this one: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 that Plymouth is actually writing to boot.log.
If you look at https://launchpadlibrarian.net/257898272/plymouth-debug.log and search in your browser for 'boot.log' you get the following lines:
[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'
I have no understanding of how the internals of Plymouth work, but since it is responsible for the splash screen that shows up before the login screen, I can only assume that if there is no splash screen (black screen) before getting to the login screen, the file is not modified. If you do have a splash screen showing before the login screen, the boot process output is redirected to the boot.log file.
Solution 2
Use journalctl
Since journald
contains all the logs, you can use the journalctl
command with suitable filters. In the case of boot.log
, which used to contain messages from the init system, you could do:
journalctl -b0 SYSLOG_PID=1
-
-b0
shows messages from the current boot,-b1
from the previous boot, and so on. Without the-b
option,journalctl
will show messages from the beginning of the log. -
SYSLOG_PID
filters messages from PID 1, aka init.
Or:
journalctl -b0 --system _COMM=systemd
-
_COMM=systemd
looks for messages from thesystemd
command. Sincesystemd
is init, this is the one we're interested in. -
--system
filters messages from the system log instead of user session logs.
Example:
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 <muru-vm>.
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
opens the logs in a pager by default, so you don't need to pipe to less
.
Persistent logging
Ubuntu, by default, does not enable persistent journald logs. Thanks to the comment by @Auspex, you need to do either of:
-
Edit
/etc/systemd/journald.conf
to include:Storage=persistent
-
Create a
/var/log/journal
directory manually:mkdir /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald
Related:
Solution 3
In Ubuntu 16.04 the boot.log
file is still located in the /var/log
folder as you can see here. The boot logfile is from today (2016-04-29). Maybe something went wrong when you installed Ubuntu 16.04 or have upgraded the operating system from Ubuntu 15.10 to Ubuntu 16.04 LTS.
Alternatively you can examine the general boot behavior from the comprehensive kern.log
file. Another possible alternative would be to manually configure the syslog daemon to generate the boot log file and here is a tutorial how exactly to do this : How To View and Configure Linux Logs
Additional information :
I investigated the boot logging behavior on two different machines. On a computer with an UEFI based BIOS the boot.log
file exists - but on a computer with legacy based BIOS it seems to not exist at all. So in case the system is installed in legacy BIOS (MBR/msdos) mode, this could be the explanation why your boot.log
file is dated from 2016-04-22, it's a leftover from Ubuntu 15.10.
Updated information 2016-05-02 :
I kept on investigating the behavior of the boot logging file and observed that the boot.log
file still exists on the UEFI based machine, but since a few days the file is empty. Another alternative I tried to see what happens during the boot process, was to install BootChart, but bootchart.png
did not exist in the /var/log
folder as expected after rebooting the system ... there only was an empty /var/log/bootchart
folder which also did not contain the expected bootchart.png
file.
Updated information 2016-05-04 :
Today the boot.log
file seemed to have "functionality" again, it is filled with partial information from the boot process. It appears to be a randomly changing behavior, that I think can't be solved here on Ask Ubuntu - so you should consider to file a bug report on Launchpad to get this solved !
Conclusion - after one week of investigation of the boot.log
file behavior in Ubuntu 16.04 : You shouldn't worry about /var/log/boot.log
any longer and just get used to journalctl
instead.
Related videos on Youtube
![jasmines](https://i.stack.imgur.com/lWUVB.png?s=256&g=1)
Comments
-
jasmines almost 2 years
I noticed that my
/var/log/boot.log
file has date 2016-04-22, last time I booted in 15.10. Where are Xenialboot.log
files located?-
Admin about 8 yearsIs real question not logging, but seeing what is slowing boot. Now you use
systemd-analyze blame
and/orsystemd-analyze critical-chain
. I do find that easier than digging thru log files to find what is causing an issue. -
Admin about 8 yearsso, none of you can say why boot.log is held on 2016-04-22... ? REALLY?
-
Admin about 8 years@jasmines : Unfortunately we can't tell you why this happens ... we are not the developers ... I updated my answer with some new information from today ... you should consider to file a bug report on Launchpad. :)
-
Admin about 8 years@jasmines Isn't it obvious? That's the date you last had 15.10. 16.04 no longer uses
boot.log
. Ergo, last date on which boot.log was update = last date you had 15.10. -
Admin about 8 years@muru why do you say that 16.04 does not use boot.log? Mine is still updated at every boot (I am on 16.04, MBR, upgraded from 15.10) pastebin.ubuntu.com/16236745
-
Admin about 8 years@dadexix86 make a fresh installation and see for yourself.
-
Admin about 8 years@muru But the question is not about a clean install... The question is about an upgraded 16.04, in which case that file should be updated at every boot.
-
Admin about 8 years@dadexix86 why? How do you know every instance of 15.10 upgraded to 16.04 should update boot.log?
-
Admin about 8 years@muru My, bad, sorry about my English. Not every system. But what one would assume is some kind of consistency. So, on my system it gets updated, on cl-netbox's it gets updated, the OP asks "why not on mine?"
-
Admin about 8 years@dadexix86 I would assume a bug. Since systemd was used since 15.04, journald would also have been used since at least as long. So, having a boot.log is rather pointless IMO. I'm surprised 15.10 even has a boot.log; any use it has is covered by
journalctl
with appropriate options. Your English is fine; OP can do with being a bit more polite. -
Admin about 8 yearsLet us continue this discussion in chat.
-
Admin about 8 yearsjournalctl is not showing what I see in splash during boot, and I need that
-
Admin about 5 yearsthat nice looking log with "[FAILED]" in red, did you manage to get that again? my file is from 2017...
-
-
jasmines about 8 yearsdon't think something went wrong, anyway I would like to accept your answer if you could add suggestions about how to solve my problem...
-
Admin about 8 yearsOn my fresh install of Ubuntu 16.04 I have also found that the
boot.log
file is not in its usual location. -
cl-netbox about 8 years@ParanoidPanda : On both machines mentioned I performed a clean / fresh installation (not an upgrade) of Ubuntu 16.04 LTS - it seems that the former way of boot logging is not properly supported anymore. :)
-
Admin about 8 years@cl-netbox: Maybe you should ask the developers of the program which is meant to generate that log. Because perhaps it is just a bug.
-
jasmines about 8 yearswhat about answer why boot.log is held on 2016-04-22... ?
-
muru about 8 years@jasmines maybe they decided to stop using
boot.log
in 16.04. -
dadexix86 about 8 yearsMine is working, last updated today. I am on MBR system, upgraded from 15.10. @jasmines is your /var/log/boot.log still held on?
-
jasmines about 8 yearsjournalctl is not showing what I see in splash during boot, and I need that
-
jasmines about 8 yearsjournalctl is not showing what I see in splash during boot, and I need that
-
muru about 8 years@jasmines and what is it you're seeing during boot? The full journalctl output will no doubt have it.
-
jasmines about 8 yearsI'm seeing what was logged in boot.log before, that format: [ OK ] Started Self Monitoring and Reporting Technology (SMART) Daemon. Mounting Arbitrary Executable File Formats File System... [ OK ] Started Login Service. Starting LSB: Start NTP daemon... [ OK ] Started Avahi mDNS/DNS-SD Stack. [ OK ] Started Make remote CUPS printers available locally. [ OK ] Started Modem Manager. [ OK ] Started Network Manager. Starting Network Manager Wait Online... [ OK ] Reached target Network. [ OK ] Started Accounts Service. and so on...
-
web.learner about 8 yearsKeep your tone and words nice. There is a be nice policy. Follow it.
-
jasmines about 8 yearsUnfortunately, I do have the splash, but no boot.log...
-
Mike about 8 years
journalctl -bX
is useless for this, id does not contain messages that really appear on screen during boot, only boot.log does and it works only sometimes on 16.04, the only way is to take a photo or write it down. I have the same problem. -
muru about 8 years@Mike and what problem is that?
journalctl
contains all the logs, it's just a matter of applying the right filters. Without knowing what you're looking for, there's nothing I can do. -
Mike about 8 yearsAs jasmines already mentioned, boot messages starting with [ OK ] ... this stuff is in boot.log but in journalctl it is little different, even when using flags like -b0 SYSLOG_PID=1 or -b1 for previous boot, not everything was there, specially errors I encountered and I could not find anywhere in logs. Most of the messages are there, I do not know how to reproduce this problem so I can not help, but it was error with kernel and it was not to be found, problem disappeared now, but I still don't see reason why boot messages are not logged exactly as they appear on screen.
-
muru about 8 years@Mike something that begins with OK is not an error. So, here you're interested in the error you saw. That's what you should be focusing on, not the format of boot.log unlike jasmines
-
Mike about 8 yearsThe line with error did not have OK, it was just me describing most of content I have seen on the screen, now I know I should have taken a photo, it is hard to prove/find something that does not exist, PC froze on boot with an error related to kernel that was not in kernel log or journalctl, I believe that journalctl is a great tool, but this is very hard to explain because boot.log was empty and journalctl, dmesg, syslog or kernel.log had no similar error messages to show, how to debug? Problem is not there after kernel upgrade, but question is why the message was not logged in boot.log?
-
Chris Good about 8 yearsI also have this problem in Ubuntu 16.04 (upgraded from 14.04). There is no useful msg in output of 'journalctl', /forcefsck has been removed but 'dumpe2fs -h /dev/sda1' shows 'Last checked' has not been updated. It seems fsck has not been run?
-
Auspex over 7 yearsIt's a good answer except for one thing. Persistent journals are not enabled on a fresh ubuntu install, at least as of LTS 16.04.1 (ie, if you don't have
/var/log/journal/
you don't have persistent journalling. You can either change/etc/journald.conf
to includeStorage=persistent
or create/var/log/journal/
asroot:systemd-journal
with modedrwxr-sr-x+
) -
Aquarius Power about 5 yearsany way to filter only what has "[FAILED]" as we see on the red messages so fast we cant even read'em?
-
Adrian about 5 yearsI confirm that when configuring
GRUB_CMDLINE_LINUX_DEFAULT=""
in/etc/default/grub
thanboot.log
is not written. When usingGRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
thanboot.log
is again written. I use Ubuntu 19.04. -
Laurent Simon almost 4 yearsThese commands do not give the equivalent of
boot.log
content.boot.log
gives far more than that!