4

This issue began when I force-shutdown my system during an update. After that, I could only boot by changing the boot parameter in grub from "ro" to "rw". Then, every time I boot, when I run fsck, I get the following output.

0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

What can I do to repair my filesystem?

2 Answers 2

2

You probably have a system with UEFI, and the error message is related to the FAT32 filesystem's "dirty bit" on the EFI System Partition (ESP). This partition is usually mounted as /boot/efi, but some distributions mount it in a different location (possibly /boot) or leave it completely unmounted except when actually updating the kernel and/or bootloader.

Resetting the dirty bit is something fsck.vfat (which is also used for FAT32 filesystem) can certainly do. However, some versions of it will need an option to actually write changes to the filesystem. Check the man page of fsck.vfat for details applicable to your specific version.

You can simply unmount the ESP filesystem, then check it. Never check any FAT32 filesystem while it's still mounted - otherwise the filesystem driver in the kernel will just overwrite the "dirty bit" again when the filesystem is accessed.

Changing the boot parameter from ro to rw is very likely hiding another problem your system has. There might be another filesystem needing checking. Perhaps it's your root filesystem?

If the boot process is stopping and leaving you in text-mode command prompt, this is precisely to allow you to run a filesystem check for your root partition while regular utilities are not yet allowed to write to it. That is normally the only way to run a filesystem check on the root partition without first booting the system from another media.

If you run a check on your root filesystem and it makes any changes to the filesystem, you should reboot immediately after the check is completed. The kernel may still have some already-read blocks from before the changes cached in memory, and if the root filesystem is remounted write-enabled without rebooting first, it might write those blocks (and the errors within them) right back onto the disk.

2
  • 1
    You're right that it's /boot/efi because sudo fsck /boot/efi shows the dirty bit. However I couldn't get fsck.vfat to work: it just outputs open: Is a directory, even if I unmount /boot/efi first. Also, could this relate to a non-clean windows shutdown (I have a dual boot). EDIT: I can reset the dirty bit with plain fsck but the error recurs. EDIT: If I remove the dirty bit with plain fsck, unmount, and then remount /boot/efi again, the error recurs. Sep 3, 2020 at 2:42
  • After unmounting /boot/efi you cannot target fsck to /boot/efi because it is then just an ordinary empty directory on the root/boot filesystem. You'll need to target the corresponding partition instead. For example, if /boot/efi is located in the first partition of the first disk (you can check with lsblk while it is still mounted), the command would be sudo fsck /dev/sda1.
    – telcoM
    Oct 5, 2022 at 19:54
0

For RHEL 7, I did the following:

To list your disks:

df -h 

or

lsblk

To unmount the disk you want to repair (in the example below /dev/sda1):

umount /dev/sda1

To clear the dirty bit and repair the disk:

fsck /dev/sda1 -a -w

NOTE: The above commands are fsck.vfat which is for fat. It seems that depending on the file system, a different version of fsck will run and different parameters may be required. In fsck.vfat, -a is automatic repair and -w is write the changes immediately.

To mount the disk again:

mount /dev/sda1

To reboot the system:

systemctl reboot

or just

reboot

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .