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
| 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.
