/ forcefsck之后，引导时在哪里记录了fsck结果？

37

远程工作时，我将服务器设置为在引导时使用sudo touch /forcefsck命令强制fsck 并重新引导。

重新启动后，我检查/var/log/fsck了磁盘检查的结果。
无论checkfs和checkroot说：什么也没有尚未登陆

那么将结果保存在哪里呢？

boot logging fsck

— 巴特·西尔弗斯特里姆
source

在Ubuntu 12.04 LTS上也有同样的问题。我在/var/log/boot.log中找到了fsck日志。

15

您可能会受到以下错误的影响：“不在/ var / log / fsck /中记录fsck调用”

— 溅
source

最有可能的。不应再惊讶，因为它可能不会被解决...

— Bart Silverstrim

这也会以非常负面的方式影响我们-我们使用的是EC2，当服务器重新启动时，我们需要诸如此类的细节。如何将其视为“愿望清单”项目？这是核心功能，并且已损坏。

— tamale 2013年

@tamale你完全正确。我也受到了打击。我的/分区有一个令人讨厌的怪癖，当进入恢复模式时，它强加了一个e2fsck。这是完美的，但是由于很难记住要从备份中替换的文件，因此一个文件必须能够跟踪据说损坏的文件名。

— 语法错误

13

对于Ubuntu 14.xx：

我发现有一些fsck登录/var/log/upstart/mountall.log。

— y
source

1

欢迎来到Ask Ubuntu。;-)当时在11.10中存在一个错误，因此您在新系统上的答案现在并没有为这个已有3年历史的问题增加任何价值。对于未来：查看问题的日期以及是否已经有答案。;-)

— Fabby 2015年

4

@Fabby，但对于将来的访问者来说，它可能仍然有用，我想？给出了版本（@Shay是指14.04还是14.10？），因此我会说这是一个有效的答案，尽管它可能对OP（3年前找到解决方案的人没有帮助...）

— Byte Commander

我添加了一个标签，以帮助搜索引擎将其显示为一个老问题。

— NGRhodes 2015年

绝对正确！:-)这就是为什么我只留下评论。记录下来：我没有投票！;-)

— Fabby 2015年

1

@Byte Commander这个“老”问题确实帮了我很多忙！我永远也不会猜到fsck日志会被隐藏起来/var/log/upstart/mountall.log。/var/log/upstart/mountall.*.log.gz。相当不合逻辑。但是，似乎没有记录到报告为已损坏的文件名，而是仅记录了它们的inode。

— 语法错误

6

对于Ubuntu 16.04和18.04 根分区

您可能正在寻找/run/initramfs/fsck.log。

根文件系统的fsck必须在根文件系统以可写方式安装之前发生，因此文件系统检查是在引导过程的早期进行的，而系统仍从initramfs运行。fsck日志被写入到RAM支持的文件系统（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
----------------

— ven42
source

1

对于根分区，这似乎是16.04 + systemd的唯一正确答案。

— 约拿·布劳恩

5

对于Ubuntu 16.04

命令 journalctl -b --no-pager | grep systemd-fsck

报告非根分区文件系统检查。类似于此：

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

— 怪胎长老
source

2

使用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

— 巴布克
source

0

对于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结果挂载的根分区检查也未记录。

— 怪胎长老
source