启动时间，/forcefsck之后，fsck的结果被记录在哪里？

Question

启动时间，/forcefsck之后，fsck的结果被记录在哪里？

52

在远程工作时，我设置了一个服务器，在启动时使用命令强制执行fsck：

sudo touch /forcefsck

然后重新启动。

重启后，我在/var/log/fsck中检查了磁盘检查的结果。 checkfs和checkroot都显示：

Nothing has been logged yet

那么结果保存在哪里呢？

- Bart Silverstrim

在Ubuntu 12.04 LTS上遇到相同的问题。我在/var/log/boot.log中找到了fsck日志。 - user143312

7个回答

18

可能你受到了这个错误的影响："在/var/log/fsck/中不记录fsck调用"。

关于这个错误，Doug的评论提出了以下的解决方法（格式已经调整适应本平台）：

告诉系统在启动时强制检查/etc/fstab中所有文件系统并指示进行文件系统检查：

touch /forcefsck

告诉系统在启动时更加详细：

sudo sed -i "s/VERBOSE=no/VERBOSE=yes/" /etc/default/rcS

然后，在重新启动后，检查/var/log/boot.log，文件系统检查的结果将在其中显示。

如果您还希望文件系统检查执行所有修复，请进行以下更改：

sudo sed -i "s/FSCKFIX=no/FSCKFIX=yes/" /etc/default/rcS

告诉系统在启动时强制检查/etc/fstab中所有文件系统并指示进行文件系统检查：

touch /forcefsck

告诉系统在启动时更加详细：

sudo sed -i "s/#VERBOSE=no/VERBOSE=yes/" /etc/default/rcS

然后，在重新启动后，检查/var/log/upstart/mountall.log，文件系统检查的结果将在其中显示。

如果您还希望文件系统检查执行所有修复，请进行以下更改：

sudo sed -i "s/#FSCKFIX=no/FSCKFIX=yes/" /etc/default/rcS

- splash

很可能。不应该再感到惊讶，因为它很可能不会得到解决... - Bart Silverstrim

这对我们产生了非常负面的影响 - 我们使用的是EC2，当服务器重新启动时，我们需要类似这样的详细信息。这怎么可能被视为一个“心愿单”项目呢？这是核心功能，而且它出现了问题。 - tamale

@tamale 你说得没错。我也遇到了这个问题。我的 / 分区有一个很讨厌的问题，在进入恢复模式时，它强制执行了 e2fsck。这是完美的，但由于很难记住哪些文件需要从备份中替换，我们必须能够追踪到据报损坏的文件名。 - syntaxerror

15

对于Ubuntu 14.xx：

我在/var/log/upstart/mountall.log中找到了一些fsck日志。

- Shay

1欢迎来到Ask Ubuntu。;-) 在那个时候，11.10版本曾经存在一个bug，所以你现在对一个三年前的问题给出的答案并没有任何价值。以后请注意查看问题的日期和是否已经有了答案。;-) - Fabby

5@Fabby但对于以后的访问者来说，我认为这仍然可能有用，你觉得呢？版本已经给出（@Shay，你是指14.04还是14.10吗？），因此我认为这是一个有效的回答，尽管它可能对楼主没有帮助（楼主在3年前就找到了解决方案...） - Byte Commander

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

完全正确！ :-)这就是我刚刚留下评论的原因。请记住：我没有点踩！;-) - Fabby

2@Byte Commander 这个看似“老旧”的问题确实帮了我很多！我真的无法想象 fsck 的日志会被隐藏在 /var/log/upstart/mountall.log 或者 /var/log/upstart/mountall.*.log.gz 这些地方。相当不合理。然而，似乎被报告为损坏的文件名字并没有被记录下来，只有它们的索引节点。 - syntaxerror

也帮助了我。 - Organic Marble

8

对于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

- Elder Geek

5

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

- Elder Geek

2非常好，谢谢你。我确认它在20.04 LTS版本中也可以正常工作。 - xCovelus

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

- barbuk

0

对于Ubuntu Server 22.04 LTS

 /run/initramfs/fsck.log

- Tiago

- ven42 · Accepted Answer

对于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
----------------