/var/log/boot.logファイルの日付が2016年4月22日で、前回15.10。で起動したことに気付きました。Xenial boot.logファイルはどこにありますか？

つかいます journalctl

以来journald、すべてのログが含まれている、あなたは使用することができjournalctl、適切なフィルタを使用してコマンドを。boot.loginitシステムからのメッセージが含まれていたの場合、次のことができます。

journalctl -b0 SYSLOG_PID=1

• -b0 現在のブートからのメッセージを表示します。 -b1、以前のブートからの。-bオプションを指定しないjournalctlと、ログの先頭からメッセージが表示されます。
• SYSLOG_PID PID 1、別名initからのメッセージをフィルタリングします。

または：

journalctl -b0 --system _COMM=systemd

• _COMM=systemd からのメッセージを探します systemdコマンド。以来systemdinitにされ、これは我々が興味を持っているものです。
• --system ユーザーセッションログの代わりにシステムログからメッセージをフィルタリングします。

例：

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 デフォルトでページャーでログを開くので、パイプする必要はありません less。

永続的なロギング

Ubuntuはデフォルトで、永続的なjournaldログを有効にしません。@Auspexのコメントのおかげで、次のいずれかを行う必要があります。

1. /etc/systemd/journald.conf含めるように編集：

   Storage=persistent
   

2. /var/log/journalディレクトリを手動で作成します。

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

関連：

• CentOS 7で以前のブートからのログメッセージを表示するにはどうすればよいですか？

私はいくつかのバグレポートを調べていましたが、これに気付きました： https //bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 Plymouthが実際にboot.logに書き込んでいる。

https://launchpadlibrarian.net/257898272/plymouth-debug.logを見て、ブラウザで「boot.log」を検索すると、次の行が表示されます。

[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'

私はプリマスの内部がどのように機能するのか理解していませんが、ログイン画面の前に表示されるスプラッシュ画面を担当しているため、ログイン画面に到達する前にスプラッシュ画面（黒い画面）がない場合にのみ想定できます、ファイルは変更されません。ログイン画面の前にスプラッシュ画面が表示されている場合、起動プロセスの出力はboot.logファイルにリダイレクトされます。

あなたが見ることができるようにUbuntu 16.04では、boot.logファイルはまだ/var/logフォルダにありますここに。ブートログファイルは今日（2016-04-29）のものです。Ubuntu 16.04をインストールしたとき、またはオペレーティングシステムをUbuntu 15.10からUbuntu 16.04 LTSにアップグレードしたときに何か問題が発生した可能性があります。

または、包括的なkern.logファイルから一般的なブート動作を調べることができます。別の可能な代替方法は、syslogデーモンを手動で構成してブートログファイルを生成することです。これを正確に行う方法は次のとおりです。Linuxログを表示および構成する方法

追加情報 ：

2つの異なるマシンでのブートロギングの動作を調査しました。UEFIベースのBIOSを搭載したコンピューターでは、boot.logファイルが存在ますが、レガシーベースのBIOSを搭載したコンピューターにはまったく存在しないようです。したがって、システムがレガシーBIOS（MBR / msdos）モードでインストールされている場合、これはboot.logファイルの日付が2016-04-22である理由の説明である可能性があります。これはUbuntu 15.10の残り物です。

更新情報2016-05-02：

ブートロギングファイルの動作を調査し続け、boot.logファイルがUEFIベースのマシンにまだ存在することを観察しましたが、数日後、ファイルは空になります。ブートプロセス中に何が起こるかを確認しようとした別の選択肢は、BootChartをインストールすることでしたが、システムを再起動した後、期待どおりにフォルダーにbootchart.png存在しませんでした/var/log... /var/log/bootchart予想も含まれていない空のフォルダーのみがありましたbootchart.pngファイル。

更新された情報2016-05-04：

今日は boot.logファイルには再び「機能」があるように思われ、ブートプロセスからの部分的な情報で満たされています。これはランダムに変化する振る舞いのようです。AskUbuntuではここで解決できないと思います。この問題を解決するには、Launchpadにバグレポートを提出することを検討してください。

結論boot.log -Ubuntu 16.04 でのファイルの動作に関する1週間の調査の後：/var/log/boot.logもう心配する必要はなく、journalctl代わりに慣れるだけです。