All of our important data sits in a file system of one type or another, and file system issues are bound to happen. On Linux, we can use the
fsck command to find and fix file system errors.
File Systems Are Software
File systems are one of the most critical components of a computer. Without a file system, the computer can’t store any data on a hard drive, whether that drive is a spinning mechanical platter or a solid-state drive. In fact, a file system has to be created before the operating system can be installed on the hard drive. There has to be something for the operating system files to be stored in. So a file system is created during the installation process.
File systems are created by software, written to by software, and read from by software. As you know, all complex software has bugs. Our data is critically important to us, so we’re putting a lot of faith in file systems and the software that creates and uses them. If something goes wrong, we can lose access to portions of the file system or even an entire partition.
Modern journaling file systems are better at handling problems that can be caused by a sudden loss of power or a system crash. They’re robust, but they’re not invincible. If their internal tables get scrambled they can lose track of where each file resides on the drive, what size it is, what name it has, and what file permissions are set on them.
fsck command lets you check that your file systems are healthy. If it finds any problems it can usually fix them for you too.
Do the Preflight Checks
fsck requires sudo privileges. Any command that can make changes to a file system needs to be treated with caution and restricted to those who know what they’re doing.
Pilots don’t jump into an aircraft, start it up, and fly off into the pale blue yonder. They do preflight checks. There’s too much at stake to do otherwise. That’s a good habit to develop. Before you use
fsck you need to ensure you’re going to use it on the correct drive. So before doing anything with
fsck, we’re going to do a bit of reconnaissance.
We’ll start with
fdisk and pipe it into
less. We’re not asking for information on a specific partition. By using the
-l (list) option
fdisk lists the partition tables on all devices it finds in the “/proc/partitions” file, if it exists.
sudo fdisk -l | less
We can see the entries for
/dev/sdb. You can scroll through the file to see any other entries that might exist on your computer.
The partitions on
/dev/sda are listed as
/dev/sda3 . So we have three partitions on the first drive. We can see a little more information by using the
parted command. We’ll use the
'print' option to display the partition tables in the terminal window.
sudo parted /dev/sda 'print'
We get some extra information this time, including the type of file system on each partition.
Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 540MB 538MB fat32 EFI System Partition boot, esp 3 540MB 34.4GB 33.8GB ext4
There are three drives in this test computer. These are the results for the other two drives
/dev/sdc. Note that these file systems have no “Name” field.
sudo parted /dev/sdb 'print'
Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdb: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 21.5GB 21.5GB primary ext4
sudo parted /dev/sdc 'print'
Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdc: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 21.5GB 21.5GB primary ext3
The second and third drives happen to be the same size, and each has a single partition. But the file system on the second drive is
ext4, and the file system on the third drive is the older
We pass a partition identifier to
fsck, and it checks the file system on that partition. But we can’t run
fsck on a mounted file system. We need to unmount the drive. To do that we need to know the mount point that the partition—and therefore the file system—is mounted on.
We can find that out easily using the
Using the fsck Command
We’ve got all the information we need. The first thing we’ll do is unmount the file system we’re going to check. We’re going to work on the file system on the first—and only—partition of
/dev/sdb, which is
/dev/sdb1 . We saw earlier that this is an
ext4 file system, and it is mounted at “/run/mount/dave/sata2.”
We’ll use the
umount command. Note there is no “n” in “umount.”
sudo umount /run/mount/dave/sata2
umount, no news is good news. If you’re returned silently to the command prompt, we’re good to go.
sudo fsck /dev/sdb1
This file system is reported as being clean. That means the file system is reporting that it has no errors or issues. A deeper file system check is not automatically conducted. We can also look at the return code that
fsck returned to the shell.
The return value of zero indicates no errors. The possible return codes are:
- 0: No errors
- 1: Filesystem errors corrected
- 2: System should be rebooted
- 4: Filesystem errors left uncorrected
- 8: Operational error
- 16: Usage or syntax error
- 32: Checking canceled by user request
- 128: Shared-library error
Despite the file system being reported as clean, we can force a file system check to take place, using the
-f (force) option.
sudo fsck /dev/sdb1 -f
This time, the check takes longer to complete but it performs a more thorough test of the file system. Our file system was indeed clean, and no errors are reported. If issues are found as the tests are being conducted, you’ll be prompted to let
fsck fix the issue or ignore the error.
When you have finished testing, you need to remount the file system. The easiest way to do this is to use
mount with the
-a (all) option. This checks “/etc/fstab” for the list of file systems, and makes sure they are all mounted just as they would be following a regular boot.
sudo mount -a
Note that we don’t need to tell
fsck what type of file system is on a partition; the utility determines that by examining the file system. That means we can force a file system check on
ext3 file system on our test PC, using exactly the same command we used on
/dev/sdb1, which is an
sudo fsck /dev/sdc1 -f
You might not want to dive straight into fixing the file system. You might prefer to look before you leap. You can ask
fsck not to offer to fix anything and just report issues to the terminal window. The
-N (dry run) option does just that:
sudo fsck -N /dev/sdb1
The opposite of that is to tell
fsck to not bother prompting if it finds any errors, and to just go ahead and fix them. To do this, use the
-y (no prompts) option.
sudo fsck -y /dev/sdb1
Using fsck On the Root Partition
You can’t use
fsck on a mounted partition, but to boot your computer the root partition must be mounted. So how can we run
fsck on the root partition? The answer is to interrupt the boot process and run
fsck in recovery mode.
While your computer is booting, hold down a “Shift” key. If you’ve timed it right you won’t boot into Linux. The boot process will stop at a black and white menu. The test machine used for this article was running Ubuntu but other distributions have the same type of menu, although it may vary in appearance. Where it says “Ubuntu” in the screenshots it will have the name of your distribution.
Move the highlight bar with the “Up Arrow” and “Down Arrow” keys so that the “Advanced options for Ubuntu” menu item is selected. Hit “Enter” to move to the next screen.
Select the option that ends with “(recovery mode).” In our example, it is “Ubuntu, with Linux 5.11.0-20-generic (recovery mode).” Hit the “Enter” key.
You’ll see the recovery menu. Select “fsck check all file systems” and press the “Tab” key to move the highlight to the “OK” button. Press “Enter.”
You’ll see a notification that the root partition will be mounted along with any other partitions defined in your “/etc/fstab” file.
Press the “Tab” key to move the highlight to the “Yes” button and press “Enter.”
fsck run in interactive mode. If there are problems you’ll be prompted to let
fsck fix them or to ignore them. When the file systems have been checked you’ll see the recovery menu again.
Select the “resume” option, press the “Tab” key to move the highlight to the “Ok” button, and press “Enter.” The boot process will resume, and you’ll boot into Linux.
The recovery mode boot can affect some drivers, so it’s good practice to reboot once more, as soon as you boot into Linux. This ensures your computer is operating in its standard fashion.
When Things Go Wrong
Safety nets are there for a reason. Get to know the
fsck command. If the need arises to use it in anger one day, you’ll be glad you familiarized yourself in advance.