2

The fsck(8) manpage on Linux includes the following table of exit codes:

   The exit code returned by fsck is the sum of the following conditions:

          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

Exit code 2 has been allocated to 'System should be rebooted', so we can probably assume it has some purpose. Yet in principle fsck could return this exit code after checking some kind of external thumb drive that isn't critical to the operation of the system at all. It seems absurd that an error in a non-essential file system like this would necessitate a reboot, especially if the file system has only been touched by fsck.

What does a 'System should be rebooted' exit code actually mean?

Improve this question

2 Answers 2

Reset to default
3

It means that the filesystem in question was mounted while the check was being performed, fsck had to actually modify data on-disk to fix an error, and the filesystem can't be manually remounted without rebooting the system.

The primary case for this is when errors are found (and repaired) on the root filesystem. Unless you have a really fancy initramfs or recovery environment you're checking the filesystem from, you're running off of the root filesystem while you're checking it (thus it's mounted read-only).

For performance reasons, the kernel doesn't revalidate cached metadata for mounted filesystems (because nothing (other than fsck should be changing the data on-disk other than the kernel for a mounted filesystem), so if fsck has to fix some of that metadata, it either needs to notify the kernel (which it can't on most UNIX systems), or tell the user to unmount the filesystem and then mount it again to get the kernel to pick up the modified metadata. The only way to do that with the root filesystem though is to actually restart the system itself.

Improve this answer
4
  • Couldn't one just use pivot_root(2) to switch to some tmpfs, unmount the original root and re-mount it again? This should address any concerns about cached data structures, but technically isn't rebooting. Commented Aug 25, 2019 at 16:47
  • @user3840170 The thing is, a reboot always works, and doesn't need special setup like using pivot_root`` (or kexec) would. You could indeed do a double pivot_root` through a specially prepared tmpfs instance (or use kexec to just reload the kernel from scratch), but fsck can't make the assumption that you have such things set up (or even know how to do so), and absolutely shouldn't do it itself (for multiple reasons), so it's left with the only option being to give the user a simple easily understood result. Commented Aug 26, 2019 at 13:12
  • So it really means "filesystem needs a remount", and reboot is the easy and reliable way to do that. Commented Apr 21, 2023 at 7:34
  • @starblue Historically, the only way to do that for the root filesystem was a reboot. And even with a modern system designed for it, you need to completely shut down all of userspace to do it because absolutely nothing can be using it, and for most users that’s functionally equivalent to a reboot, albeit possibly much faster. Commented Apr 22, 2023 at 11:35
1

It really does mean that the system should be rebooted.

fsck implementations are typically careful about returning this code only when necessary: for example, e2fsck returns it if it corrected errors on the root file system, while it was mounted (it is typically mounted read-only until it’s been checked). You shouldn’t get it on an external drive.

Note that you should check the documentation for the specific checkers being used. For example, fsck.fat doesn’t use the same exit codes, and blindly assuming that an exit code of 2 means to reboot could lead to surprises.

Improve this answer
4
  • Thing is, the main /sbin/fsck binary may use bitwise OR to combine exit codes coming from different filesystem-specific fsck binaries; for this operation to make sense, there really should be some common interpretation for these exit codes. fsck.fat not using these standard codes is a bug, which presumably will be fixed in some future release. Commented Aug 25, 2019 at 16:58
  • Yes, I agree it’s a bug; unfortunately that doesn’t change the fact that you can’t rely on the codes having a common meaning, you need to check first. (And yes, I think all fscks you’d use on a root file system do follow the main fsck expectations.) Commented Aug 25, 2019 at 18:48
  • If the only sensible action in that case is to reboot, why doesn't fsck just invoke reboot(2) on its own, or send SIGINT to PID 1? The reboot must be for some reason other than 'because I said so'. Commented Sep 3, 2019 at 8:31
  • One tool, one job. fsck’s job is to check and fix file systems, not to handle rebooting. Arguably the documentation assumes too much; it would be more accurate to say “2 indicates that a mounted file system was altered” (which in practice means the system should be rebooted). Commented Sep 3, 2019 at 9:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.