Khi làm việc từ xa, tôi đặt một máy chủ để buộc fsck khi khởi động bằng sudo touch /forcefscklệnh và khởi động lại.
Sau khi nó khởi động lại, tôi đã kiểm tra /var/log/fsckkết quả kiểm tra đĩa.
Cả checkfs và checkroot đều nói: Chưa có gì được ghi lại
Vậy nó đang lưu kết quả ở đâu?
Câu trả lời:
Có thể bạn bị ảnh hưởng bởi lỗi này: "Không đăng nhập các yêu cầu fsck trong / var / log / fsck /"
/Phân vùng của tôi có một sự khó chịu và khi vào chế độ phục hồi, nó buộc phải sử dụng e2fscknó. Điều này là hoàn hảo, nhưng vì thật khó để nhớ những tập tin nào cần thay thế từ bản sao lưu, người ta phải có thể theo dõi các tên tập tin bị hỏng.
Tôi tìm thấy một số nhật ký fsck trong /var/log/upstart/mountall.log.
fsckcác bản ghi sẽ được ẩn đi trong sự tôn trọng /var/log/upstart/mountall.log. /var/log/upstart/mountall.*.log.gz. Khá phi logic. TUY NHIÊN, có vẻ như các tên tệp được báo cáo là không được ghi lại, chỉ là các nút của chúng.
Đối với phân vùng gốc Ubuntu 16.04 và 18.04
Bạn có thể đang tìm kiếm /run/initramfs/fsck.log.
Một fsck của hệ thống tập tin gốc nhất thiết phải xảy ra trước khi hệ thống tập tin gốc được gắn kết là có thể ghi, do đó kiểm tra hệ thống tập tin xảy ra sớm trong quá trình khởi động trong khi hệ thống vẫn đang chạy từ initramfs. Nhật ký fsck được ghi vào hệ thống tệp được hỗ trợ RAM (tmpfs) có sẵn để ghi vào thời điểm này và nó tiếp tục khả dụng sau khi khởi động tại /run/initramfs/fsck.log. Đây là lưu trữ dễ bay hơi, vì vậy nhật ký fsck bị mất khi hệ thống khởi động lại. Sẽ thật tuyệt nếu các nhật ký này được sao chép vào bộ lưu trữ không bay hơi sau khi hệ thống tập tin gốc được gắn kết là có thể ghi, nhưng điều này dường như không xảy ra.
Đây là một ví dụ:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 238G 0 part /
$ cat /run/initramfs/fsck.log
Log of fsck -C -a -V -t ext4 /dev/sda2
Fri Nov 30 22:35:21 2018
fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2
/dev/sda2: clean, 653295/15597568 files, 6658147/62383360 blocks
Fri Nov 30 22:35:21 2018
----------------
Dành cho Ubuntu 16.04
Lệnh
journalctl -b --no-pager | grep systemd-fsck
báo cáo hệ thống tập tin phân vùng không root kiểm tra giống như thế này:
Mar 22 15:06:26 64bitUbuntu systemd-fsck[750]: /dev/sdb1: clean, 146223/121454592 files, 356711795/485818368 blocks
Để kiểm tra phân vùng gốc khi khởi động, lệnh
more /var/log/boot.log
Cung cấp kết quả tương tự như thế này:
/dev/sda2: clean, 349091/1954064 files, 2379983/7814912 blocks
Thử nghiệm điều này với Ubuntu 12.04.5 LTS và tôi đã tìm thấy nhật ký trên /var/log/boot.log
└❯ grep -A 1 fsck /var/log/*
/var/log/boot.log:fsck from util-linux 2.20.1
/var/log/boot.log-/dev/vda1: 209262/2621440 files (0.1% non-contiguous), 3239494/10485504 blocks
Dành cho Ubuntu 18.04
Lệnh journalctl -b --no-pager | grep systemd-fsckvàgrep systemd-fsck /var/log/syslog
cả hai báo cáo hệ thống tập tin phân vùng không root kiểm tra giống như thế này:
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[615]: Scratch: clean, 19/6520832 files, 555602/26081280 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[609]: /dev/sda1: clean, 47014/89374720 files, 294970235/357492992 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[613]: /dev/sda5: clean, 6707/32727040 files, 7464312/130885120 blocks
Kiểm tra các phân vùng gốc được gắn kết quả UUID dường như không được ghi lại ngay cả khi bị ép buộc.