Skip to main content

Does the Linux kernel need a file system to run? [Resolved]

My opinion is yes, it does, because all useful exposure to the outside world (non-priviledged processor mode) would first require a process running in the outside world. That would require a file system, even a temporary, in-RAM, file system.

Another engineer disagrees with me, but I can't seem to prove this beyond all (unknown to me) cases.

Does the answer to this question depend on the definition of 'running'?

Question Credit: Peter L.
Question Reference
Asked March 23, 2019
Posted Under: Unix Linux
3 Answers

The answer is going to depend on whether you literally mean without a file system or if the question is intended to be interpreted a little different from how it is actually stated. The answers for slight variations in how the question is interpreted are:

  • Running Linux without any block devices is entirely feasible and useful for some specialized use cases.
  • Running Linux without any file system is going to require rewriting some parts of the kernel code and it's unlikely to be a useful effort.
  • Running Linux without using any file descriptors is going to require a lot of effort. I'm pretty sure that's not going to be worth the effort.

The reasons you'd have to rewrite parts of the kernel code to make a working system without a file system are:

  • Every thread has a root directory and a current working directory which must point to some file system.
  • Programs are started by the execve system call which needs an executable from a file system.
  • The kernel creates a memory based file system during the boot process.

After a program has been started using execve it is possible for it to unmap the executable from which it was started, though in order to do so it without immediately crashing it first have to create an executable memory mapping which isn't backed by a file, and it has to initialize that with some useful code before jumping to it and unmapping the executable.

Thus a running user mode program can exist in a state where it has no memory mappings backed by files and it can close all file descriptors backed by files. It cannot stop having a root directory and current working directory, but it can refrain from those.

So though in this state you could implement kernel code to rip the file system away from under the program and have it keep running, it doesn't sound like it's useful. And getting into that final state without going through an intermediate state of using a file system is going to be even more work for no useful benefit.

A useful setup for some specialized use cases

Avoiding the use of block devices can be useful. During boot the kernel creates a memory file system, and it can also populate that file system with contents from a cpio archive before executing init. That way you can run a system entirely from a memory based file system without any block device to back it.

This can be useful for systems where you don't want to preserve any state and like the system to start from a clean slate upon rebooting.

Of course the kernel and cpio archive have to get somehow exist in memory before the kernel is given control. How they got there is a job for the boot loader. The boot loader could have loaded those from a block device even though the final running system doesn't use block devices. But it's also possible for the boot loader to acquire the kernel and cpio archive without using a block device for example by booting over the network.

credit: kasperd
Answered March 23, 2019

In Linux, every device is a file, so you have to have a filesystem to run it.

credit: K7AAY
Answered March 23, 2019
Your Answer