当我在更新期间强制关闭系统时，出现了此问题。之后，我只能通过将grub中的启动参数从“ro”更改为“rw”来启动。然后，每次启动时，当我运行 fsck 时，我都会得到以下输出。
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
我可以做什么来修复我的文件系统？
答案1
您可能有一个带有 UEFI 的系统，并且错误消息与 EFI 系统分区 (ESP) 上的 FAT32 文件系统的“脏位”有关。该分区通常安装为/boot/efi，但某些发行版将其安装在不同的位置（可能/boot）或将其完全卸载，除非实际更新内核和/或引导加载程序。
重置脏位fsck.vfat（也用于 FAT32 文件系统）当然可以做到。但是，它的某些版本需要一个选项来实际将更改写入文件系统。查看 的手册页，fsck.vfat了解适用于您的特定版本的详细信息。
您可以简单地卸载 ESP 文件系统，然后检查它。切勿在安装时检查任何 FAT32 文件系统 - 否则，当访问文件系统时，内核中的文件系统驱动程序将再次覆盖“脏位”。
将启动参数从 更改ro为rw很可能隐藏系统存在的另一个问题。可能还有另一个文件系统需要检查。也许这是你的根文件系统？
如果启动过程停止并让您处于文本模式命令提示符状态，则这是恰恰允许您对根分区运行文件系统检查，而常规实用程序尚不允许对其进行写入。这通常是在根分区上运行文件系统检查而无需首先从其他介质引导系统的唯一方法。
如果您对根文件系统运行检查并且对文件系统进行了任何更改，则应在检查完成后立即重新启动。内核可能仍然有一些在更改之前已读取的块缓存在内存中，如果根文件系统在不重新启动的情况下重新挂载为可写，则它可能会将这些块（以及其中的错误）立即写回到磁盘上。
答案2
对于 RHEL 7，我执行了以下操作：
列出您的磁盘：
df -h
或者
lsblk
要卸载要修复的磁盘（在下面的示例中为 /dev/sda1）：
umount /dev/sda1
要清除脏位并修复磁盘：
fsck /dev/sda1 -a -w
注意：以上命令是 fsck.vfat，适用于 fat。似乎根据文件系统的不同，将运行不同版本的 fsck，并且可能需要不同的参数。在fsck.vfat中，-a是自动修复，-w是立即写入更改。
再次挂载磁盘：
mount /dev/sda1
重新启动系统：
systemctl reboot
要不就
reboot