If the file systems are meant to do fsck while booting, why is Linux not able to do fsck sometimes, and going into maintenance mode?

  • This question is meaningless without specifying the operating system, which it does not specify. (Linux is not an operating system.) Because only by knowing the operating system will one know whether the premise of the question is even true in the first place. What happens upon fsck failure is highly dependant from the operating system's choice of system management, and for some choices this premise is false.
    – JdeBP
    Jan 7, 2020 at 19:50
  • 1
    Could you possibly give a bit more context to your question, including what Linux you are using, what filesystem type you are using, and what errors fsck is encountering?
    – Kusalananda
    Jan 7, 2020 at 20:44
  • The fsck, or "disk check" operation should not be required in normal circumstances. If you're having it happen regularly there's something else at play - for example, perhaps you're pulling the power on your computer rather than shutting it down cleanly (from software). Jan 7, 2020 at 20:48

1 Answer 1


In general, a Linux system will run full fsck at boot-up for three reasons only:

  1. the maximum mount count for the filesystem was reached (an fsck resets it)
  2. the fs was not unmounted cleanly (system crash, power failure, hard power reset, etc), so the "clean" flag was not set for the filesystem.
  3. you specifically told it to.

If the fsck drops you into maintenance mode, it was probably for a good reason; the filesystem was in a state that was deemed to be beyond automatic repair.

If this happens often, then you have something wrong with the system. Without extremely detailed data, it's impossible to tell if the problem lies with the physical disk itself, the connectors, the disk driver, the user, or something else entirely. User error (e.g. pulling the plug instead of waiting for a clean shutdown) is a very common cause, and should be the first thing to check.

  • It's worth remembering that mke2fs has not defaulted to setting a maximum mount count since 2011. unix.stackexchange.com/a/47884/5132 Also note that the real set of reasons is not uniformly hardwired into the various underlying fsck tools. e2fsck, for one, has more than those 3 scenarios. It also looks for an exceeded check interval or mismatched superblock features, for starters.
    – JdeBP
    Jan 8, 2020 at 14:10

You must log in to answer this question.

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