How to set filesystems mount order on modern Linux distributions

In a previous tutorial we discussed about the /etc/fstab file, and how it is used to declare the filesystems which should be mounted on boot. In the pre-Systemd era, filesystem where mounted in the order specified in the /etc/fstab file; on modern Linux distributions, instead, for a faster boot, filesystem are mounted in parallel. Systemd manages the mounting of filesystems via specifically designed units automatically generated from /etc/fstab entries. For these reasons a different strategy must be adopted to establish the dependency between two filesystems, and therefore to set their correct mount order.

In this tutorial we see how to establish an explicit dependency between two filesystems and set their mount order on modern Linux distributions.

In this tutorial you will learn:

  • How entries in the /etc/fstab file are transformed in Systemd mount units
  • How Systemd “mount” units are structured
  • How to establish a dependency between two filesystems in /etc/fstab
How to set filesystems mount order on modern Linux distributions
How to set filesystems mount order on modern Linux distributions

 

Software requirements and conventions used
Category Requirements, Conventions or Software Version Used
System Distributions which uses Systemd
Software No specific software needed
Other Administrative privileges
Conventions # – requires given linux-commands to be executed with root privileges either directly as a root user or by use of sudo command $ – requires given linux-commands to be executed as a regular non-privileged user

Systemd “mount” units

Systemd is the init system adopted on practically every major Linux distribution out there. Systemd does a lot more than just managing system initialization in the traditional sense. On modern Linux distributions it manages also the mounting of filesystem via “mount” units, whice are similar to the “service” units  used to manage services. The traditional way to set which filesystems should be mounted on boot was to use the fstab file. While this method still works, under the hood fstab entries are transformed  into “mount” units by systemd-fstab-generator and  “stored” in the /run/systemd/generator directory.

Anatomy of a mount unit

Mount units have the “.mount” suffix and must be named after the mountpoint they control. An unit used to mount the filesystem which should be mounted on the /home directory, for example, must be named “home.mount”.  Let’s see an example of how mount units are generated from entries in fstab. In the /etc/fstab file, I configured a filesystem to be mounted on /home:

/dev/sda3 /home ext4 defaults 1 2



For the sake of this example, the filesystem was created on the /dev/sda3 partition. It is an “ext4” filesystem configured to be mounted on /home with the “default” options. Below you can see the corresponding “.mount” unit generated by systemd-fstab-generator  as /run/systemd/generator/home.mount:

# Automatically generated by systemd-fstab-generator

[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
Requires=systemd-fsck@dev-sda3.service
After=systemd-fsck@dev-sda3.service
After=blockdev@dev-sda3.target

[Mount]
What=/dev/sda3
Where=/home
Type=ext4

The first thing we see in the file is a comment stating the the unit was generated automatically by systemd-fstab-generator. We can observe that the unit has two sections: [Unit] and [Mount].

The [Unit] stanza contains generic information about the unit: it is common to all types of systemd units. The Documentation keyword is used to reference documentation related to the unit (in this case the man page of fstab and the system-fstab-generator).

The SourcePath keyword, instead, is used to reference the source from which the unit was generated, which in this case is the /etc/fstab file.



The Before, After and Requires keywords are used to establish unit dependencies and their order. For example, by using Before=local-fs.target, it is established that before the system can reach the “local-fs.target”, the unit must be executed (the After keyword works in the opposite way: for the unit to be started, the mentioned units must be fully started).

The [Mount] stanza is specific to “.mount” units. In this case it contains three keywords: What, Where and Type. The first keyword is used to reference the full path of the resource which should be mounted, the second takes the absolute path of the mountpoint where the resource should be mounted as value; the third is used  to specify the filesystem type.

Establishing dependencies and mount order in /etc/fstab

In which cases we may want to establish a dependency between two filesystems? Suppose we have a filesystem which we mount on the /home directory, and another one containing a specific user data which we want to mount on a sub-directory of its home (e.g: /home/egdoc/data). This setup establishes a “dependency” between the two filesystem, since for the second to be mounted successfully, the first one should be already mounted.

In this case, since the second mountpoint is beneath the first one, we shouldn’t do anything special. Systemd is intelligent enough to establishing a dependency between the two filesystems, therefore in the fstab file we would just write:

/dev/sda3 /home ext4 defaults 1 2
/dev/sda4 /home/egdoc/data ext4 defaults 1 2



What if we want to explicitly establish a dependency between two filesystems with “unrelated” mountpoints? To accomplish this task we have to use the x-systemd.requires-mounts-for option. This option takes an absolute path as a value, and establish a dependency between the filesystem for which it is used and the fileystem used for mountpoint passed as value.

Let’s see an example. Suppose for some reason we want the filesystem mounted on /home to be mounted after the one mounted on /boot (which below we assume being on the /dev/sda2 partition). In /etc/fstab we would write:

/dev/sda2 /boot   ext4 defaults 1 2
/dev/sda3 /home ext4 defaults,x-systemd.requires-mounts-for=/boot 1 2

For the systemd mount units to be regenerated immediately, we could run:

$ sudo systemctl daemon-reload

At this point, if we take a look at the /run/systemd/generator/home.mount unit, we can see the RequiresMountsFor=/boot option have been included in the [Unit] stanza:

# Automatically generated by systemd-fstab-generator 

[Unit] 
Documentation=man:fstab(5) man:systemd-fstab-generator(8) 
SourcePath=/etc/fstab 
RequiresMountsFor=/boot 
Before=local-fs.target 
Requires=systemd-fsck@dev-sda3.service 
After=systemd-fsck@dev-sda3.service 
After=blockdev@dev-sda3.target 

[Mount]
What=/dev/sda3
Where=/home
Type=ext4
Options=defaults,x-systemd.requires-mounts-for=/boot

Conclusions

Nowadays almost every major Linux distribution has (not without any controversy), adopted Systemd as init system. One of the biggest critics used against Systemd is that it just does a lot more than managing system initialization. In this case we saw how it handles also the mounting of filesystems at boot, via specific units which can be written from scratch or generated automatically from the traditional /etc/fstab file. Since  the mounting of filesystem is not performed sequentiallyat boot, in this tutorial we saw how to declare the dependency between two filesystems and set their correct mount order using the x-systemd.requires-mounts-for option.



Comments and Discussions
Linux Forum