Tôi nhận thấy rằng /var/log/boot.logtệp của tôi có ngày 2016-04-22, lần cuối cùng tôi khởi động vào 15.10. Các boot.logtập tin Xenial nằm ở đâu?

Sử dụng journalctl

Vì journaldchứa tất cả các bản ghi, bạn có thể sử dụng journalctllệnh với các bộ lọc phù hợp. Trong trường hợp boot.log, được sử dụng để chứa các tin nhắn từ hệ thống init, bạn có thể làm:

journalctl -b0 SYSLOG_PID=1

• -b0hiển thị các thông báo từ lần khởi động hiện tại, -b1từ lần khởi động trước, v.v. Nếu không có -btùy chọn, journalctlsẽ hiển thị các thông báo từ đầu nhật ký.
• SYSLOG_PID lọc các tin nhắn từ PID 1, còn gọi là init.

Hoặc là:

journalctl -b0 --system _COMM=systemd

• _COMM=systemdtìm kiếm tin nhắn từ systemdlệnh. Vì systemdlà init, đây là thứ chúng tôi quan tâm.
• --system lọc các thông điệp từ nhật ký hệ thống thay vì nhật ký phiên của người dùng.

Thí dụ:

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

journalctlmặc định mở các bản ghi trong một máy nhắn tin, vì vậy bạn không cần phải chuyển sang less.

Ghi nhật ký liên tục

Ubuntu, theo mặc định, không kích hoạt các bản ghi nhật ký liên tục. Nhờ nhận xét của @Auspex , bạn cần thực hiện một trong hai cách sau:

1. Chỉnh sửa /etc/systemd/journald.confđể bao gồm:

   Storage=persistent
   

2. Tạo một /var/log/journalthư mục thủ công:

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

Liên quan:

• Làm cách nào để hiển thị thông báo nhật ký từ các lần khởi động trước trong CentOS 7?

Tôi đã xem qua một số báo cáo lỗi và nhận thấy trong báo cáo này: https://bugs.launchpad.net/ubfox/+source/ubuntu-gnome-default-sinstall/+bug/1536771 rằng Plymouth thực sự đang viết cho boot.log.

Nếu bạn xem https://launchpadlibrarian.net/257898272/plymouth-debug.log và tìm kiếm trong trình duyệt của bạn để tìm 'boot.log', bạn sẽ nhận được các dòng sau:

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

Tôi không hiểu cách thức hoạt động của các bộ phận bên trong Plymouth, nhưng vì nó chịu trách nhiệm cho màn hình giật gân xuất hiện trước màn hình đăng nhập, tôi chỉ có thể giả sử rằng nếu không có màn hình giật gân (màn hình đen) trước khi vào màn hình đăng nhập , tập tin không được sửa đổi. Nếu bạn có màn hình giới thiệu hiển thị trước màn hình đăng nhập, đầu ra của quá trình khởi động được chuyển hướng đến tệp boot.log.

Trong Ubuntu 16.04, boot.logtệp vẫn nằm trong /var/logthư mục như bạn có thể thấy ở đây . Logfile khởi động là từ hôm nay (2016-04-29). Có thể đã xảy ra lỗi khi bạn cài đặt Ubuntu 16.04 hoặc đã nâng cấp hệ điều hành từ Ubuntu 15.10 lên Ubuntu 16.04 LTS.

Ngoài ra, bạn có thể kiểm tra hành vi khởi động chung từ kern.logtệp toàn diện . Một cách khác có thể là cấu hình thủ công syslog daemon để tạo tệp nhật ký khởi động và đây là hướng dẫn cách thực hiện chính xác: Cách xem và cấu hình Nhật ký Linux

Thông tin thêm :

Tôi đã điều tra hành vi đăng nhập khởi động trên hai máy khác nhau. Trên máy tính có BIOS dựa trên UEFI, boot.logtệp tồn tại - nhưng trên máy tính có BIOS dựa trên di sản thì dường như không tồn tại. Vì vậy, trong trường hợp hệ thống được cài đặt ở chế độ BIOS kế thừa (MBR / msdos), đây có thể là lời giải thích tại sao boot.logtệp của bạn có niên đại từ 2016-04-22, đó là phần còn lại từ Ubuntu 15.10.

Thông tin cập nhật 2016-05 / 02:

Tôi tiếp tục điều tra hành vi của tệp ghi nhật ký khởi động và quan sát thấy boot.logtệp vẫn tồn tại trên máy dựa trên UEFI, nhưng sau vài ngày tệp trống. Một cách khác tôi đã cố gắng để xem những gì xảy ra trong quá trình khởi động, là cài đặt BootChart , nhưng bootchart.pngkhông tồn tại trong /var/logthư mục như mong đợi sau khi khởi động lại hệ thống ... chỉ có một /var/log/bootchartthư mục trống cũng không chứa bootchart.pngtệp dự kiến .

Thông tin cập nhật 2016-05-04:

Ngày nay, boot.logtập tin dường như có "chức năng" một lần nữa, nó chứa đầy thông tin một phần từ quá trình khởi động. Nó dường như là một hành vi thay đổi ngẫu nhiên, mà tôi nghĩ rằng không thể giải quyết ở đây trên Hỏi Ubuntu - vì vậy bạn nên xem xét để gửi báo cáo lỗi trên Launchpad để giải quyết vấn đề này!

Kết luận - sau một tuần điều tra về boot.loghành vi tệp trong Ubuntu 16.04: Bạn không nên lo lắng về vấn đề này /var/log/boot.lognữa và chỉ cần làm quen với journalctlnó.