问题描述
远程工作时，我将服务器设置为在启动时使用sudo touch /forcefsck命令强制执行fsck并重新启动。
重新启动后，我检查了/var/log/fsck以获取磁盘检查的结果。 checkfs和checkroot都说：还没有记录任何内容
那么它在哪里节省了结果呢？
最佳解决方案
可能您受此错误的影响：“Does not log fsck invocations in /var/log/fsck/”
次佳解决方案
对于Ubuntu 14.xx：
我在/var/log/upstart/mountall.log中找到了一些fsck日志。
第三种解决方案
对于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 16.04和18.04根分区
您可能正在寻找/run/initramfs/fsck.log。
根文件系统的fsck必须在根文件系统挂载为可写之前发生，因此在系统仍在从initramfs运行时，文件系统检查会在引导过程的早期发生。 fsck日志写入此时可用于写入的RAM-backed文件系统(tmpfs)，并在/run/initramfs/fsck.log引导后继续可用。这是易失性存储，因此一旦系统重新启动，fsck日志就会丢失。如果在将根文件系统挂载为可写之后将这些日志复制到non-volatile存储器会很好，但事实并非如此。
这是一个例子：
$ 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
----------------