Filesystems and the single-user mode

Hierarchy

Article from Issue 187/2016
Author(s):

maddog explains the importance of single-user mode and filesystem hierarchy standards.

A friend of mine was trying to shut his system down to single-user system (SUS) mode. Although many modern-day GNU/Linux users probably do not know what SUS is, the "old people" who are familiar with Unix and earlier versions of GNU/Linux certainly are aware of it.

SUS is when most of services – such as web servers, database engines, and other "service" features – are shut down. Users (even local users) cannot log onto the system and, typically, the graphics from the X Window System are also turned off. More importantly (for my friend), all of the filesystems other than the root filesystem (represented by /) are unmounted and idle.

In this state, the systems administrator can fix many things that are wrong without completely shutting down the system and turning off the power. In this state, the admin can move things around in the filesystems or make a filesystem bigger or move it to another disk.

However a filesystem cannot be cleanly unmounted if an application is still using it, so applications tend to be placed in the file tree according to when they are needed. To explain this, I must go back in time…

GNU/Linux is based on the Unix operating system, which was started in 1969. At the time, a disk that was 5 or 10 megabytes was considered large, and even though Unix systems of the time were textually oriented (avoiding the large storage needs of audio, video, and graphical interfaces), they were still time-sharing systems and needed more storage space than a single 5MB disk could supply.

Therefore, Ken Thompson and Dennis Ritchie developed an extensible filesystem in the tree-like fashion that we all know and love. They also developed directories as "mount points" so the filesystem could literally be extended as far as people wanted (with as many disks as the machine could handle). The only limitation was that a filesystem could not span a disk drive. This limitation was overcome eventually by the use of virtual disks, or volumes, but for most filesystems, the same limitation exists today.

This system was set up so it could perform such functions as boot, launch the kernel, access most (if not all) of the devices, do backups of the filesystems, and do filesystem work. (Networking was typically not turned on in single-user mode.) The filesystems of the day were not as robust as most GNU/Linux filesystems, and often after a crash, you needed to run a program called fsck to check and fix the filesystems; otherwise, filesystem damage could occur that would eventually make the filesystem unusable.

Another advantage of the filesystem tree was to give systems administrator some leverage as to what type or speed of device they could use. If there was an application such as a database engine, for example, the administrator could put it on its own device and make sure the device was a large, fast one. To the user, it would look like just another part of the filesystem.

The system was set up to reflect this filesystem hierarchy. However, because there was also a policy of having binaries in /bin and libraries in /lib with everything else in /etc, when the filesystem expanded to include /usr, it was decided to put the things used by all users in /usr/bin, /usr/lib, and /usr/etc to allow more binaries and libraries than what a 5MB disk could hold.

Likewise, a user could have a ~/bin, ~/lib, and ~/etc in her own home directory. This meant that all of the applications that needed to run in single-user mode (when no other filesystems were mounted) had to have all of their associated binaries in /bin, libraries in /lib, and other files handily in /etc.

Thus, began my friend's problems. He wanted to take the system down to single-user mode and unmount the /usr filesystem to do some work on it. However, once in single-user mode, he could not umount /usr because dbus was using some libraries in /usr/lib and he could not run the system without dbus.

He went onto Facebook and started complaining about this to his friends. They belittled him because the days of 5MB disks are gone now, and they called him "old." He replied, saying there was a standard called the Filesystem Hierarchy Standard (FHS), which states that programs that run in single-user mode need to have all of their binaries and libraries in the root filesystem. People laughed at that, too.

It is not a laughing matter. The FHS was written with a lot of care and thought as to how a Unix (and GNU/Linux) system should run. People need the concept of a standalone root filesystem, and we need to keep checking that we can still do this.

The Author

Jon "maddog" Hall is an author, educator, computer scientist, and free software pioneer who has been a passionate advocate for Linux since 1994 when he first met Linus Torvalds and facilitated the port of Linux to a 64-bit system. He serves as president of Linux International®.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Admin Workshop: Unix filesystem tree

    Unix systems organize files in a hierarchical filesystem tree. A system of naming conventions defined in the Filesystem Hierarchy Standard (FHS) helps admins find their way around.

  • Configuring Filesystems

    Although most Linux distributions today have simple-to-use graphical interfaces for setting up and managing filesystems, knowing how to perform those tasks from the command line is a valuable skill. We’ll show you how to configure and manage filesystems with mkfs, df, du, and fsck.

  • FSlint

    FSlint detects the source of filesystem problems and remedies or mitigates them while cleaning up the hard drive.

  • Resetting Passwords with SystemRescueCd

    If you’re locked out of your Linux or Windows system, a handy Live Linux troubleshooting distro might be all you need to get back in. We’ll show you how to pick the lock with SystemRescueCd.

  • Encrypted Filesystems

    If you’re not a security expert and you're looking for a crypto filesystem, you may be wondering about the alternatives. We took at a look at some popular crypto options for Linux.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News