I noticed that my
/var/log/boot.log file has date 2016-04-22, last time I booted in 15.10. Where are Xenial
boot.log files located?
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
-b0shows messages from the current boot,
-b1from the previous boot, and so on. Without the
journalctlwill show messages from the beginning of the log.
SYSLOG_PIDfilters messages from PID 1, aka init.
journalctl -b0 --system _COMM=systemd
_COMM=systemdlooks for messages from the
systemdis init, this is the one we're interested in.
--systemfilters messages from the system log instead of user session logs.
muru@muru-vm:~$ journalctl -b0 SYSLOG_PID=1 Apr 30 12:29:18 muru-vm systemd: systemd 229 running in system mode. (+PA Apr 30 12:29:18 muru-vm systemd: Detected virtualization qemu. Apr 30 12:29:18 muru-vm systemd: Detected architecture x86-64. Apr 30 12:29:18 muru-vm systemd: Set hostname to <muru-vm>. Apr 30 12:29:18 muru-vm systemd: Initializing machine ID from random gene Apr 30 12:29:18 muru-vm systemd: Installed transient /etc/machine-id file Apr 30 12:29:18 muru-vm systemd: Set up automount Arbitrary Executable Fi Apr 30 12:29:18 muru-vm systemd: Listening on fsck to fsckd communication Apr 30 12:29:18 muru-vm systemd: Reached target User and Group Name Looku Apr 30 12:29:18 muru-vm systemd: Listening on udev Kernel Socket. Apr 30 12:29:18 muru-vm systemd: Started Forward Password Requests to Wal Apr 30 12:29:18 muru-vm systemd: Listening on /dev/initctl Compatibility Apr 30 12:29:18 muru-vm systemd: Listening on Journal Socket. Apr 30 12:29:18 muru-vm systemd: Created slice User and Session Slice. Apr 30 12:29:18 muru-vm systemd: Created slice System Slice. Apr 30 12:29:18 muru-vm systemd: Starting Braille Device Support... Apr 30 12:29:18 muru-vm systemd: Mounting POSIX Message Queue File System Apr 30 12:29:18 muru-vm systemd: Mounting Debug File System... Apr 30 12:29:18 muru-vm systemd: Mounting Huge Pages File System... Apr 30 12:29:18 muru-vm systemd: Starting Load Kernel Modules... Apr 30 12:29:18 muru-vm systemd: Starting Uncomplicated firewall... Apr 30 12:29:18 muru-vm systemd: 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
Ubuntu, by default, does not enable persistent journald logs. Thanks to the comment by @Auspex, you need to do either of:
mkdir /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald
3journalctl is not showing what I see in splash during boot, and I need that May 6, 2016 at 4:59
1I'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... May 6, 2016 at 5:18
journalctl -bXis 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.– MikeMay 18, 2016 at 17:55
1As 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.– MikeMay 18, 2016 at 18:35
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.
Unfortunately, I do have the splash, but no boot.log... May 13, 2016 at 4:38
3I confirm that when configuring
boot.logis not written. When using
boot.logis again written. I use Ubuntu 19.04.– AdrianJun 9, 2019 at 11:21
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
Updated information 2016-05-04 :
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
don't think something went wrong, anyway I would like to accept your answer if you could add suggestions about how to solve my problem... Apr 29, 2016 at 11:14
Tried to manually configure the syslog daemon to generate the boot log file following the tutorial. I added # Save boot messages also to boot.log local7.* /var/log/boot.log to my /etc/rsyslog.d/50-default.conf file no luck, /var/log/boot.log is still 2016-04-22 May 2, 2016 at 10:55
On my fresh install of Ubuntu 16.04 I have also found that the
boot.logfile is not in its usual location.– user364819May 2, 2016 at 11:52
@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. :) May 2, 2016 at 12:31
3journalctl is not showing what I see in splash during boot, and I need that May 6, 2016 at 5:00
systemd-analyze critical-chain. I do find that easier than digging thru log files to find what is causing an issue.