1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
---
title: Mount Requirements
category: Booting
layout: default
SPDX-License-Identifier: LGPL-2.1-or-later
---
# Mount Point Availability Requirements
This document describes the requirements placed by systemd
on the time when various parts of the file system hierarchy
must be available and mounted during boot.
This document should be read in conjunction with
[UAPI.9 Linux File System Hierarchy](https://uapi-group.org/specifications/specs/linux_file_system_hierarchy/),
which describes the role of the mount points discussed here.
If the file system backing a mount point is located on external or remote media
that require special drivers, infrastructure or networking to be set up,
then this implies that this functionality must be started and running
at the point in the boot sequence when that mount point is required.
There are three general categories of mount points:
1. 🌥️ *initrd*: File system mounts that must be established before the OS
transitions into the root file system. (I.e., must be mounted in
the initrd before the initrd→host transition takes place.)
2. 🌤️ *early*: File system mounts that must be established
before the end of "early boot", i.e. before `local-fs.target` is reached.
All services that do not explicitly opt-out of the dependency
are ordered after that point.
3. ☀️ *regular*: File system mounts that can be mounted later.
Individual services might pull in specific mount points and be ordered after them.
Mount points that require network to be available
are typically ordered before `remote-fs.target`.
Those mount points may be established as automount points.
Mounts in the later categories may be established earlier,
i.e. mounts that fall into category 2/early may also be mounted in the initrd,
and mounts in category 3/regular may also be mounted in the initrd or early boot.
Since mount points that are lower in the hierarchy are mounted later,
if a mount point is *not* split out,
but a given subtree is part of the parent mount,
the requirements for that subtree are trivially satisfied by the parent.
A "mount point" in this document means the whole subtree of the hierarchy,
until a mountpoint lower in the hierarchy which is conceptually separate.
For example, on a system with a custom mount point located below `/var/spool/`,
most of `/var/` would be in category 2/early,
but the additional mount would be in category 3/regular.
Conversely, if some part of `/usr/` that is normally part of that subtree
was split out to a separate mount,
this mount point would fall into category 1/initrd
and configuration would need to be provided for it to be mounted in the initrd.
Here's a table with relevant mounts and to which category they belong:
| *Mount* | *Category* |
|---------------|------------|
| `/` (root fs) | 1/initrd |
| `/usr/` | 1/initrd |
| `/etc/` | 1/initrd |
| `/var/` | 2/early |
| `/var/tmp/` | 2/early |
| `/tmp/` | 2/early |
| `/home/` | 3/regular |
| `/srv/` | 3/regular |
| XBOOTLDR | 3/regular |
| ESP | 3/regular |
Or in other words: the root file system (obviously…), `/usr/` and `/etc/` (if
these are split off) must be mounted at the moment the initrd transitions into
the host. Then, `/var/` (with `/var/tmp/`) and `/tmp/` (if split off) must be
mounted before the host reaches `local-fs.target` (and then `basic.target`),
after which any remaining mounts may be established.
If mounts such as `/var/` are not mounted during early boot (or from the
initrd), and require some late boot service (for example a network manager
implementation) to operate this will likely result in cyclic ordering
dependencies, and will result in various forms of boot failures.
Also note that the whole of `/var/` (including `/var/tmp/`), and `/tmp/` must
be *writable* at the moment indicated above. It's OK if they are mounted
read-only at an earlier time as long as they are remounted writable by the
indicated point in time. Systems where these three hierarchies remain read-only
during regular operation are not supported by `systemd`.
An exception to the rules described above are ephemeral systems,
where the root file system is initially an empty `tmpfs` mount point
and parts of the file system hierarchy are populated by systemd during early boot.
If you intend to use network-backed mounts (NFS, SMB, iSCSI, NVME-TCP and
similar, including anything you add the `_netdev` pseudo mount option to) for
any of the mounts from category 1/initrd or 2/early,
make sure to use a network manager that is capable of running in the initrd or early boot.
[`systemd-networkd(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd.html)
for example works well in such scenarios.
[`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.html)
is an example of a regular service from category 3/regular.
It runs after `basic.target` and requires `/home/` to be mounted.
|
