เมื่อทำงานจากระยะไกลฉันจะตั้งเซิร์ฟเวอร์ให้บังคับ fsck ณ เวลาบูตด้วยsudo touch /forcefsckคำสั่งและรีบูท
หลังจากรีสตาร์ทฉันเช็คอิน/var/log/fsckเพื่อดูผลการตรวจสอบดิสก์
ทั้งสองcheckfsและcheckrootกล่าวว่าไม่มีอะไรที่ได้รับการบันทึกไว้เลย
ดังนั้นมันอยู่ที่ไหนบันทึกผลลัพธ์?
คำตอบ:
อาจเป็นไปได้ว่าคุณได้รับผลกระทบจากข้อผิดพลาดนี้: "ไม่บันทึกการเรียกใช้ fsck ใน / var / log / fsck /"
/พาร์ทิชันของฉันมีการเล่นโวหารที่น่ารังเกียจและเมื่อเข้าสู่โหมดการกู้คืนก็บังคับให้e2fsckมัน นี่เป็นสิ่งที่สมบูรณ์แบบ แต่เนื่องจากเป็นการยากที่จะจำไฟล์ที่จะแทนที่จากการสำรองข้อมูลคุณจะต้องสามารถติดตามชื่อไฟล์ที่มีรายงานว่าเสียหาย
ผมพบว่าบันทึก fsck /var/log/upstart/mountall.logบางอย่างใน
fsckบันทึกจะถูกซ่อนอยู่ในความ/var/log/upstart/mountall.logเคารพ /var/log/upstart/mountall.*.log.gz. ค่อนข้างไร้เหตุผล อย่างไรก็ตามดูเหมือนว่าชื่อไฟล์ที่รายงานว่าเสียหายจะไม่ถูกบันทึก แต่เป็นเพียงไอโหนด
สำหรับ Ubuntu 16.04 และ 18.04 พาร์ติชั่นรูต
/run/initramfs/fsck.logคุณจะมองหา
fsck ของระบบไฟล์รูทจำเป็นต้องเกิดขึ้นก่อนที่ระบบไฟล์รูทจะได้รับการติดตั้งเพื่อให้สามารถเขียนได้ดังนั้นการตรวจสอบระบบไฟล์จะเกิดขึ้นก่อนในกระบวนการบู๊ตในขณะที่ระบบยังคงทำงานจาก initramfs บันทึก fsck ถูกเขียนไปยังแรมได้รับการสนับสนุนระบบแฟ้ม (tmpfs) /run/initramfs/fsck.logที่สามารถใช้ได้สำหรับการเขียนในเวลานี้และจะยังคงสามารถใช้ได้หลังจากที่บูต นี่คือที่จัดเก็บข้อมูลแบบระเหยดังนั้นบันทึก fsck จะหายไปเมื่อระบบรีบูต มันจะดีถ้าบันทึกเหล่านี้ถูกคัดลอกไปยังหน่วยความจำที่ไม่ลบเลือนหลังจากติดตั้งระบบไฟล์รูทเป็นแบบเขียนได้ แต่สิ่งนี้ดูเหมือนจะไม่เป็นเช่นนั้น
นี่คือตัวอย่าง:
$ 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
----------------
สำหรับ Ubuntu 16.04
คำสั่ง
journalctl -b --no-pager | grep systemd-fsck
รายงานระบบไฟล์พาร์ติชันที่ไม่ใช่ root จะตรวจสอบเช่นนี้:
Mar 22 15:06:26 64bitUbuntu systemd-fsck[750]: /dev/sdb1: clean, 146223/121454592 files, 356711795/485818368 blocks
สำหรับการตรวจสอบพาร์ติชันรูทเมื่อมีการบูทออกคำสั่ง
more /var/log/boot.log
ให้ผลลัพธ์คล้ายกับสิ่งนี้:
/dev/sda2: clean, 349091/1954064 files, 2379983/7814912 blocks
ทดสอบกับ Ubuntu 12.04.5 LTS และฉันพบล็อกออน /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
สำหรับ Ubuntu 18.04
คำสั่งjournalctl -b --no-pager | grep systemd-fsckและgrep systemd-fsck /var/log/syslog
ทั้งรายงานระบบไฟล์พาร์ติชันที่ไม่ใช่รูทตรวจสอบเหมือนกัน:
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
การตรวจสอบพาร์ติชันรากที่เมาท์ด้วยผลลัพธ์ UUID จะไม่ถูกบันทึกแม้ว่าจะถูกบังคับก็ตาม