我的Ubuntu在每次启动时运行fsck
在每次启动时都是一样的：
/dev/sda1: clean, 908443/38690816 files, 44176803/154733312 blocks 它是Ubuntu用来确保文件系统一致性或者我的硬盘出现问题的某种选择吗？ 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：clean，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"),
它跳过了“全面检查”，但只是确保对期刊的一些快速测试是干净的并且没有孤立的inode：
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 systemd-fsck(8)手册页具有触发完整检查的条件：
systemd-fsck-root.service负责对根文件系统进行文件系统检查，但前提是在initramfs中未检查根文件系统。 systemd-fsck @ .service用于所有其他文件系统和initramfs中的根文件系统。
如果文件系统的/ etc / fstab中的passno设置为大于零的值，则这些服务在引导时启动。 root的文件系统检查在其他文件系统之前执行。 可以并行检查其他文件系统，除非它们位于同一个旋转磁盘上。
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需要30s而不只是下一个与udevd相关的控制台消息需要30秒吗？ 换句话说，在显示控制台消息之前，udevd可能需要30秒才能在libticables上运行超时？
尝试删除（或临时移动其他地方）
/lib/udev/rules.d/45-libticables.rules
看看是否有帮助。
由于时钟坏，每次启动时都会发生这种错误。 似乎systemd-fsck @在systemd-timesyncd之前运行，并且没有电池支持的RTC，系统时间在运行fsck时是错误的。
我确认这确实触发了全面检查（而不是快速退出fsck），禁用systemd-timesynd，将clock设置为journalctl中找到的预同步值，然后运行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? yes Pass 1: Checking inodes, blocks, and sizes ...
请注意，此完全检查的触发器与自上次检查后的最大装载计数和时间间隔的其他触发器无关，如dumpe2fs -h ，此处的其他答案中提到。
请注意，如果不设置时钟（即让timesyncd同步它），fsck将不会进行全面检查，但会通过“filesystem clean”消息快速退出。
作为一种解决方法，我通过将’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
根据您的要求定制。
正如其他人发布的那样，最大挂载计数默认为-1 ，这意味着每次启动时都会运行fsck，这自然会降低启动过程的速度。
使用以下方法将fsck的频率更改为每50个靴子或每30天更改一次：
$ sudo tune2fs -c 50 -i 1m /dev/sdc3 tune2fs 1.42.13 (17-May-2015) Setting maximal mount count to 50 Setting interval between checks to 2592000 seconds
假设今天是2016年11月13日，请检查下次运行fsck时间：
$ sudo dumpe2fs -h /dev/sdc3 | grep Next dumpe2fs 1.42.13 (17-May-2015) Next check after: Tue Dec 13 22:45:39 2016