21

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'?

Improve this question
6
  • 6
    i think that a running kernel does not "require" useful exposure to the outside world Commented Mar 21, 2019 at 23:28
  • 20
    Brings to mind the old halted Linux firewall (circa 2002) Commented Mar 22, 2019 at 0:50
  • 1
    If you add new code to the kernel, you can do anything. If you can't, it will initialize fine up to the point where it tries to run init (the first user-space process), and that will fail. Commented Mar 22, 2019 at 6:44
  • 1
    Define "run"... Commented Mar 22, 2019 at 11:49
  • Read operating system: three easy pieces Commented Mar 22, 2019 at 12:03

5 Answers 5

Reset to default
32

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.

Improve this answer
13
  • 1
    @PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC. Commented Mar 22, 2019 at 2:04
  • 5
    Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed. Commented Mar 22, 2019 at 5:37
  • 1
    @IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed). Commented Mar 22, 2019 at 17:23
  • 1
    @pizdelect If you believe the vast majority of documentation "is wrong", that should tell you something about your own understanding. /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
  • 1
    Not attacking you. Apologies if you think I am. The information I have provided is intended to give touch points onto people's understanding in order to explain the requirement for a file system. Not provide a definitive guide to booting Linux on every distribution. I deliberately trimmed out long discussion of initrd because it's not relavent. The mechanism for how /sbin/init is called from /init on initrd is also not relavent. The permutations of booting android, osx an every other Linux is irrelevant. The fact that the kernel calls a user space program on a filesystem is relavent. Commented Mar 26, 2019 at 22:47
19

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.

Improve this answer
2
  • 1
    The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'. Commented Mar 22, 2019 at 14:58
  • 2
    @PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system. Commented Mar 22, 2019 at 22:11
5

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

Improve this answer
6
  • 8
    But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them. Commented Mar 22, 2019 at 0:09
  • 6
    Not every device is a file. Network interfaces (eth0, wlan0 etc.) aren't, for example. Commented Mar 22, 2019 at 4:35
  • 1
    This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files). Commented Mar 22, 2019 at 5:34
  • @forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix. Commented Mar 22, 2019 at 9:11
  • 1
    Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ... Commented Mar 22, 2019 at 14:47
1

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.

--- addendum ---

I've examined the issue in detail against the 6.11.0 sources. Some thoughts, I consider a real "filesystem" to be an encoded block device (disk typically) or a network interface (like NSF) that presents a mountable entity of a type that might appear in /proc/filesystems. It is possible to successfully call creat, open, close, read, write, seek and unlink on such a file system. In addition modern Linux includes several pseudo-filesystems such as /proc, /sys. /dev (via devtmpfs) is a semi-real ramdisk fs, but populated by the kernel.. These pseudo-fs (/proc, /sys) are a convenient way to communicate info between user&kernel space, but not conventional filesystems.

(A) It is trivially easy to to cause the kernel to exec a program on a regular filesystem and then never again access any conventional filesystem. Just take a statically linked copy of 'yes' and copy it to /sbin/init . Even a useful binary, such as a firewall or i/o control program may have no i/o to a filesystem. This is a "stops using filesystems" method.

(B) Note that any successful call to exec() necessarily involves access to SOME filesystem. We can take a statically linked binary (like 'yes' or an i/o program) and create a kernel module with the binary blob, and have the module present the blob within one of the of the pseudo filesystems. So like:

uint8 myblob[] =  { 0x75, 0x45, .... }
sysfs_create_bin_file(&myblob, __ATTR(myinit, 0755))

This creates an pseudo-fs entry at /sys/myinit which is executable. Then if we set the kernel boot parameter "init=/sys/myinit" the kernel will exec the binary as pid=1. This is an "only uses pseudo-filesystems" method.

We can futher eliminate /dev and other ramdisks and filesystems of any sort with (CONFIG_BLOCK=n; CONFIG_NET=n). This means no disks, no ramdisk, no block devtmpfs nor tmpfs. /proc and /sys still exist, mounted on a bogus '/' root.

A control program dependent on /dev/gpiochip0 [for example] would fail - however it could use the /sys interface such as /sys/devices/pci0000:00/INT3450:00/gpiochip0 and successfully do I/O. So yes there is a method for a "useful app with no filesystem", except the /sys pseudo-fs.

Even in deeply embedded systems, removal of ramdisk for /dev/ and /tmp/ is rare, and various flash or eeprom filesystems (squashfs on a flash/eeprom) are often used. It could however be done and there are viable use-cases.

Improve this answer
4
  • Ok, what do you do with your RT if there is a bug that you can never fix because you cant coredump to real storage? Throw it away, along with any work you put into making it run? Commented Dec 21, 2024 at 2:14
  • You fail to coredump if there is no storage - it is simply a debugging aid. When was the last time you analyzed a coredump from say your android phone ? Your wifi Router ? Your cars infotainment system ? It's simply not done in many embedded applications. Commented Dec 21, 2024 at 19:41
  • k, you're probably right; I don't embed much (but I'd bet you $50 there's some reason why you can get a coredump from: an android phone, a wifi Route, a car's infotainment system, a Cray, or an x86...) Commented Dec 21, 2024 at 22:00
  • You can't generally ; your wifi router, has no storage for a coredump so they are disallowed, by the kernel config. Your android phone may have log messages and an abbreviated 'tombstone' info and logs. . Coredumps can be useful for debugging APPS. You don't really need them for something like your router b/c you can't readily introduce new apps. Andoid app developers have a lot of debug tools besides coredump in the lab. Dumps might be useful for debugging an android app, but the Java engine logs will address 99.98% of the cases. I can't remember that last time I got a coredump. Commented Dec 22, 2024 at 20:54
-1

Hm,

A kernel needs to core dump. A core dump needs permanent storage on a filesystem. A kernel needs a filesystem.

A kernel without a filesystem can't core dump and so is bound to be a machine with unspecified behaviour. A kernel can dump, hang, or exit/halt: But if a kernel can't dump you can't tell where/how it has hung while exiting.

And by "running", I think OP might mean like worth running because it's a real computer with actual work and responsibility.

Also. Can you have a unix program that produces no exit value?

No, because then it's not a UNIX program; ergo, the kernel is not a UNIX program.

Improve this answer
5
  • (1) What’s your basis for claiming “A kernel needs to core dump.”?   (2) You ask, “Can you have a unix program that produces no exit value?”  What does that have to do with this question?  If you want to dispute stevea’s answer, post a comment under that answer.  But note that the accepted answer says “you don't run the kernel like you run a program.”   (3) What’s your basis for claiming that a program that produces no exit value is not (implicitly, cannot be) ‘‘a UNIX program’’? Commented Dec 21, 2024 at 1:44
  • P.S. Please capitalize consistently. Commented Dec 21, 2024 at 1:44
  • A core dump is a binary image of an executing process at the time some unhandled event (exception or signal) occurred. Useful for debugging IF the app was compiled with debug info (big & bloaty) - which is rarely the case. W/o using compilation debug option, the info value is quite limited. More modern programming languages are memory safe and use library methods that avoid most causes of a core dump. Core-dump certainly isn't required, and is not very prominent as a debugging tool. Commented Dec 23, 2024 at 4:51
  • To avoid confusion, a coredump can help debug a user-space app. When a kernel detects an internal kernel fault it (tries to) dump registers and a "stack trace" of the kernel thread to the logs. Commented Dec 23, 2024 at 4:57
  • I guess the missing principle is that if your machine has a dollar value then there are probably other people expecting you to be able to (minimally) trap a bug on the system they are relying on, see? [Assurance] Commented Dec 24, 2024 at 21:55

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.