My opinion is yes, it does, because all useful exposure to the outside world (non-privileged 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'?
That's rather an odd question because you don't run the kernel like you run a program. The kernel is a platform to run programs on. Of course there is setup and shutdown code but it's not possible to run the kernel on its own. There must always be a main "init" process. And the kernel will panic if it's not there. If init tries to exit the kernel will also panic.
These days the init process is something like systemd. If not otherwise specified the kernel will try to run a program from a list of locations starting with /sbin/init. See the init Param here http://man7.org/linux/man-pages/man7/bootparam.7.html in an emergency you can boot Linux with init=/bin/bash . But notice how you always specify a file on the file system to run.
So the kernel will panic if it starts up an has no file system because without one there is no way to load init.
Some confusion may arise because of an initialisation phase of the kernel. An initial ramdisk is loaded from an image on disk containing vital drivers and setup scripts. These are executed before the file system is loaded. But make no mistake the initial ramdisk is itself a file system. With an initial ramdisk /init is called (which is stored on the initial ramdisk). In many distributions it is ultimately this which calls /sbin/init. Again without a file system, this is impossible.
/init is part of the startup phase which is why the line of code you refer to talks about the ramdisk ramdisk_execute_command. /init is NOT on the root file system. Sure /init could hang and never complete it's job, but on a well functioning system (like 99.9999%) it completes and at the end calls something like switch_root man7.org/linux/man-pages/man8/switch_root.8.html Or you could just ps -ef and see which process is PID 1
Commented
Mar 26, 2019 at 18:13
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:
The reasons you'd have to rewrite parts of the kernel code to make a working system without a file system are:
execve system call which needs an executable from a file system.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.
In Linux, nearly every device is a file, so you have to have a filesystem to run it.
eth0, wlan0 etc.) aren't, for example.
A kernel IS a program, just like any other. By default the Linux kernel attempts to access file system, however this behavior can be trivially eliminated by kernel modification (actually just an addition of an "arch_call_rest_init()" function). In order to perform "useful work" then we expect that the developer might include kernel threads (kthreads), perhapos in a custom driver, to perform some desired initialization and application type workload. The Linux kernel contains many kthreads already ,but primarily to perform work ancillary to the kernel or drivers. The APIs available within the kernel context are quite different from those available in Linux user-space. A large fraction of system call functionality would become useless in a no-filesystem scenario.
Yes, Linux expects access to file systems by default. No, a modified kernel could certainly be made to perform useful work w/o any file system. The practical use of Linux w/o filesystem is IMO quite limited, but not nil. FWIW, in the past many real-time kernels were built into the same name-space & binary as the RT applications.
useful exposure to the outside worldinit(the first user-space process), and that will fail.