我的Ubuntu在每次启动时都运行fsck

在每次启动时都是一样的：

/dev/sda1: clean, 908443/38690816 files, 44176803/154733312 blocks

Ubuntu是用来确保文件系统一致性的某种选择，还是我的HDD出了点问题？fsck开机时最多需要30秒，否则大约需要三倍的时间。

全部输出（部分为德语）：

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
fsck von util-linux 2.20.1
/dev/sda1: sauber, 908443/38690816 Dateien, 44176803/154733312 Blöcke
udevd[623]: unknown key 'SYSFS{idVendor}' in /lib/udev/rules.d/45-libticables.rules:6

udevd[623]: invalid rule '/lib/udev/rules.d/45-libticables.rules:6'

 * Starting mDNS/DNS-SD daemon                                                 [ OK ]
 * Starting Reload cups, upon starting avahi-daemon to make sure remote queues are populated                                                                   [ OK ]
 * Starting configure network device security                                  [ OK ]
 * Starting bluetooth daemon                                                   [ OK ]
 ####* Starting all other stuff

/ dev / sda1：干净，908443/38690816文件，44176803/154733312块

产生该消息的行是这样的：

/* Print the summary message when we're skipping a full check */
log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),

它跳过了“完全检查”，但是只是确保对日志的一些快速测试是干净的并且没有孤立的索引节点：

cat /var/log/boot.log 
fsck from util-linux 2.20.1
fsck from util-linux 2.20.1
/dev/sda1: clean, 260598/771552 files, 1684682/3080192 blocks
/dev/sdb10: recovering journal
/dev/sdb10: Clearing orphaned inode 142568 (uid=1000, gid=1000, mode=0100664, size=32768)
/dev/sdb10: Clearing orphaned inode 138527 (uid=1000, gid=1000, mode=0100600, size=9580)
/dev/sdb10: clean, 54957/991232 files, 3498365/3958006 blocks

这是正常现象，是预期的。如果是真正彻底的检查，则将花费更多时间，但通常只需要一秒钟或更短的时间。系统systemd-fsck(8)手册页具有触发完全检查的条件：

systemd-fsck-root.service负责对根文件系统进行文件系统检查，但前提是未在initramfs中检查根文件系统。systemd-fsck @ .service用于所有其他文件系统以及initramfs中的根文件系统。

如果文件系统/ etc / fstab中的passno设置为大于零的值，则这些服务将在引导时启动。在其他文件系统之前执行文件系统根检查。可以并行检查其他文件系统，除非它们位于同一旋转磁盘上。

systemd-fsck不了解有关特定文件系统的任何详细信息，仅执行特定于每种文件系统类型（/sbin/fsck.*）的文件系统检查器。该帮助程序将根据自上次检查以来的时间，安装次数，不干净的卸载等来决定是否实际检查文件系统。

您可以简单地检查一下测试是否可以运行（如果您使用systemd）：

sudo systemd-analyze blame | grep fsck
          1.608s systemd-fsck@dev-disk-by\x2duuid-408535fe\x2d28e6\x2d4d82\x2dbb59\x2d9810ead089a3.service
            87ms systemd-fsck@dev-mapper-vlhome\x2dlvhome.service

您确定是fsck花费了30秒，而不仅仅是下一个与udevd相关的控制台消息花费了30秒吗？换句话说，在显示控制台消息之前，udevd可能需要30秒超时处理libticables上的内容？

尝试移除（或暂时移动到其他地方）

/lib/udev/rules.d/45-libticables.rules

看看是否有帮助。

由于时钟错误，每次启动时都会出现此fsck。似乎systemd-fsck @在systemd-timesyncd之前运行，并且没有电池支持的RTC，因此在运行fsck时系统时间错误。

我通过禁用systemd-timesynd，将clock设置为journalctl中的预同步值并运行fsck，确实触发了完整检查（而不是快速退出fsck）。一旦e2fsck检测到最后的超级块写入时间是在将来，它将继续进行完整检查：

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Superblock last write time (Mon Jun 19 00:48:11 2017,
    now = Tue Jan 31 20:09:28 2017) is in the future.
Fix<y>? yes
Pass 1: Checking inodes, blocks, and sizes
...

请注意，完全检查的此触发器与最大装载次数和自上次检查以来的时间间隔的其他触发器无关dumpe2fs -h，如此处其他答案中提到的中所述。

请注意，如果不设置时钟（即让timesyncd对其进行同步），则fsck不会进行完整检查，但会以“文件系统清洁”消息快速退出。

解决方法是，通过将“ pass”字段设置为0来禁用/ etc / fstab中的fsck。最终，我将为此设备购买电池供电的RTC。

我的搜索得出的结论是，Ubuntu默认最大安装数设置为-1。这意味着fsck将永远不会在任何引导上运行，无论安装的数量是多少。您可以通过命令检查您的-

sudo dumpe2fs -h /dev/sda8 | grep -i 'mount count'

您可以使用来增加它tune2fs。一个典型的例子如下：

sudo tune2fs -c 30 -i 1w /dev/sda8

根据您的要求进行自定义。