On a running linux system, what is a portable (among linux distributions) way to find out what filesystems the current kernel has compiled-in (not through modules) support for?

Consider for example my current Ubuntu x86_64 kernel: 3.11.0-24-generic #41-Ubuntu. It has for instance no /proc/config.gz, which would be my first thought otherwise.

The reason I'm interested is that I'd like to (programmatically) build a rescue environment with the current kernel and an initial ramdisk that the kernel will be able to load/mount.

Is is as simple as comparing /proc/filesystems with lsmod?

If so: Do the modules always have the exact same name (first column from lsmod output) as the filesystem name (last column in /proc/filesystems)?

Is there perhaps a more modern way such as /sys instead of /proc to look for info?

My current approach is as follows. Can someone confirm that it is correct, or advise how to do it instead?:

for fscand in $(awk '{print $NF}' /proc/filesystems)
  if test $(lsmod | grep -c -e '^'${fscand}'[^a-z0-9_-]') -eq 0
    candlist="${fscand} ${candlist}"

for fscand in $candlist
  echo $fscand is compiled-in

Is is as simple as comparing /proc/filesystems with lsmod?


$ comm -31 <(lsmod | awk 'NR!=1 {print $1}' |sort) \
           <(</proc/filesystems awk '{print $NF}' |sort) | fmt
anon_inodefs autofs bdev cgroup cpuset debugfs devpts devtmpfs ext2 ext3
fuseblk fusectl hugetlbfs mqueue nfs4 pipefs proc pstore ramfs rootfs
rpc_pipefs securityfs sockfs sysfs tmpfs

Many of these are not built into the kernel on that system. autofs is provided by a modules called autofs4 while nfs4 is provided by a module called nfs. The ext4 module provides ext2 and ext3 as well as ext4; fuse provides both fuseblk and fusectl. rpc_pipefs (not to be confused with pipefs) is provided by sunrpc.

Yet your system is able to load a module for a filesystem on demand: when you run mount -t foo …, if foo isn't a supported filesystem type, Linux attempts to load a module that provides this filesystem. The way this works is that the kernel detects that foo isn't a supported filesystem, and it calls modprobe to load a module called fs-foo. The mechanism is similar to pci:… aliases to load the driver for a PCI hardware peripheral by its PCI ID and usb:… which is similar to USB — see How to assign USB driver to device and Debian does not detect serial PCI card after reboot for more explanations. The fs-… module aliases are recorded in /lib/$(uname -r)/modules.alias. This file is generated when you build the kernel.

Under normal conditions, you can use this to determine which filesystems are provided by modules. By elimintation, the filesystems that are not provided by modules are built into the kernel. There are rare edge cases where this approach wouldn't work, for example if you've modified or erased your modules.alias file, or if a filesystem is provided both by a module and in a compiled-in form. I don't know of a way to cope with these cases short of writing some kernel code and loading it as a module.

for fs in $(</proc/filesystems awk '{print "fs-" $NF}' |sort); do
  /sbin/modprobe -n $fs 2>/dev/null || echo "$fs is built in"
  • I don't get the "No:" part of this answer. It looks like you compare them just like in the question? – MattBianco Aug 4 '14 at 6:42
  • @MattBianco I compare them just like in the question, and the result is not what was desired — it includes many filesystems that are not built into the kernel but loaded by a module with a different name. So the answer is no. – Gilles Aug 4 '14 at 7:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.