如何在引导前或重新启动时fsck根文件系统
今天，我浏览了运行LinuxMint17.3肉桂的桌面站点，并对根分区进行了Ext4文件系统的检查，如下所示：
# fsck.ext4 -fn /dev/sdb2问题是，在所有的计算机上，我都看到了类似于这台电脑的东西：
e2fsck 1.42.9 (4-Feb-2014)
Warning! /dev/sdb2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 524292 has zero dtime. Fix? no
Inodes that were part of a corrupted orphan linked list found. Fix? no
Inode 524293 was part of the orphaned inode list. IGNORED.
Inode 524294 was part of the orphaned inode list. IGNORED.
Inode 524299 was part of the orphaned inode list. IGNORED.
Inode 524300 was part of the orphaned inode list. IGNORED.
Inode 524301 was part of the orphaned inode list. IGNORED.
Inode 524302 was part of the orphaned inode list. IGNORED.
Inode 524310 was part of the orphaned inode list. IGNORED.
Inode 524321 was part of the orphaned inode list. IGNORED.
Inode 524322 was part of the orphaned inode list. IGNORED.
Inode 524325 was part of the orphaned inode list. IGNORED.
Inode 2492565 was part of the orphaned inode list. IGNORED.
Inode 2622677 was part of the orphaned inode list. IGNORED.
Inode 2622678 was part of the orphaned inode list. IGNORED.
Inode 2883748 was part of the orphaned inode list. IGNORED.
Inode 2884069 was part of the orphaned inode list. IGNORED.
Inode 2885175 was part of the orphaned inode list. IGNORED.
Pass 2: Checking directory structure
Entry 'Default_keyring.keyring' in /home/vlastimil/.local/share/keyrings (2495478) has deleted/unused inode 2498649. Clear? no
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 2491790
Connect to /lost+found? no
Pass 5: Checking group summary information
Block bitmap differences: -(34281--34303) -11650577 -(11650579--11650580) -11650591 -(11650594--11650595) -(13270059--13270073) -(13272582--13272583) -(20542474--20542475) +(26022912--26023347) -(26029568--26030003)
Fix? no
Free blocks count wrong (14476802, counted=14476694).
Fix? no
Inode bitmap differences: -(524292--524294) -(524299--524302) -524310 -(524321--524322) -524325 +2491790 -2492565 -2498649 -(2622677--2622678) -2883748 -2884069 -2885175
Fix? no
Free inodes count wrong (7371936, counted=7371916).
Fix? no
/dev/sdb2: ********** WARNING: Filesystem still has errors **********
/dev/sdb2: 443232/7815168 files (0.1% non-contiguous), 16757502/31234304 blocks我试过的是：
# touch /forcefsck这将导致在启动时持续2-3秒的检查.很明显什么都没修。
这很可能是因为我的根文件系统是干净的。
# fsck.ext4 -n /dev/sdb2
e2fsck 1.42.9 (4-Feb-2014)
Warning! /dev/sdb2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sdb2: clean, 443232/7815168 files, 16757502/31234304 blocks由于除了sudo touch /forcefsck之外，几乎找不到任何文件系统检查启动的内容，所以我尝试了以下步骤：
echo u > /proc/sysrq-triggerumount /dev/sdb2fsck -fy /dev/sdb2
这确实显示了它已经修复，以确保我再次运行fsck没有错误。但是，一旦我重新启动它们就回来了。我现在很困惑。请不要像这样说“创建一个闪存驱动器并从它启动和.”。我想要一个解决方案在重新启动或重新启动之前，而不从一些闪存启动。谢谢。
回答 2
Unix & Linux用户
发布于 2016-05-05 18:28:56
首先，fsck‘s安装的文件系统预期会产生错误。文件系统不一致，因为日志没有被重放(也没有被干净地卸载)，而且您不能重播日志，因为这样做(和其他任何更改一样)会破坏文件系统。如果使用的是LVM，则可以获取快照并对快照进行fsck。
如果您使用的是SSD，fsck可以非常快。您还可以尝试使用tune2fs -C将挂载计数设置为高于最大值(可以从dumpe2fs -h获得)。
touch /forcefsck应该能工作。
编者注：
touch /forcefsck不起作用。- 请参考这个答案获得清晰的证据和解决方案。
Unix & Linux用户
发布于 2016-05-05 18:32:36
Linux 17.3基于Ubuntu14.04。
我建议您尝试标准恢复菜单，它允许您使用fsck驱动器。
一步一步的指南摘自Mint 18.3，所以它可能有点不同，因为这个版本是基于Ubuntu 16.04的：
- 在GRUB菜单中，选择Linux的高级选项。
- 欢迎您有三个选项，其中之一有(恢复模式)在最后，选择这一个。
- 现在，您有一个名为
fsck和description的选项:检查所有文件系统
https://unix.stackexchange.com/questions/281322
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号