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.
The 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
Using 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.
We can see the entries for /dev/sda and /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/sda1, /dev/sda2, and /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.
We get some extra information this time, including the type of file system on each partition.
There are three drives in this test computer. These are the results for the other two drives /dev/sdb and /dev/sdc. Note that these file systems have no “Name” field.
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 ext3.
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 df command.
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.”
With umount, no news is good news. If you’re returned silently to the command prompt, we’re good to go.
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.
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.
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 /dev/sdc1, the ext3 file system on our test PC, using exactly the same command we used on /dev/sdb1, which is an ext4 partition.
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:
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.
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.”
You’ll see 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.
