systemd中文文档

- 启动: http://systemd.cn/docs/Booting/
- 自动启动评估: http://systemd.cn/docs/Booting/AUTOMATIC_BOOT_ASSESSMENT/
- 启动组件和根文件系统探测: http://systemd.cn/docs/Booting/ROOTFS_DISCOVERY/
- 引导加载程序接口: http://systemd.cn/docs/Booting/BOOT_LOADER_INTERFACE/
- 恢复出厂设置: http://systemd.cn/docs/Booting/FACTORY_RESET/
- 挂载点可用性要求: http://systemd.cn/docs/Booting/MOUNT_REQUIREMENTS/
- TPM2 PCR测量: http://systemd.cn/docs/Booting/TPM2_PCR_MEASUREMENTS/
- Boot Loader Specification: http://systemd.cn/docs/BOOT_LOADER_SPECIFICATION/
- Discoverable Partitions: http://systemd.cn/docs/DISCOVERABLE_PARTITIONS/
- Elf Dlopen Metadata: http://systemd.cn/docs/ELF_DLOPEN_METADATA/
- Osc Context: http://systemd.cn/docs/OSC_CONTEXT/
- Package Metadata for Executable Files: http://systemd.cn/docs/PACKAGE_METADATA_FOR_EXECUTABLE_FILES/
- API File Systems: http://systemd.cn/docs/API_FILE_SYSTEMS/
- Appstream Bundle: http://systemd.cn/docs/APPSTREAM_BUNDLE/
- Backports: http://systemd.cn/docs/BACKPORTS/
- Booting Without /usr is Broken: http://systemd.cn/docs/SEPARATE_USR_IS_BROKEN/
- Code Quality Tools: http://systemd.cn/docs/CODE_QUALITY/
- Coding Style: http://systemd.cn/docs/CODING_STYLE/
- Compatibility with SysV: http://systemd.cn/docs/INCOMPATIBILITIES/
- Container Interface: http://systemd.cn/docs/CONTAINER_INTERFACE/
- Contributing: http://systemd.cn/docs/CONTRIBUTING/
- Control Group APIs and Delegation: http://systemd.cn/docs/CGROUP_DELEGATION/
- Converting Existing Users to systemd-homed: http://systemd.cn/docs/CONVERTING_TO_HOMED/
- Credentials: http://systemd.cn/docs/CREDENTIALS/
- Desktop Environment Integration: http://systemd.cn/docs/DESKTOP_ENVIRONMENTS/
- Diagnosing Boot Problems: http://systemd.cn/docs/DEBUGGING/
- File Descriptor Store: http://systemd.cn/docs/FILE_DESCRIPTOR_STORE/
- Frequently Asked Questions: http://systemd.cn/docs/FAQ/
- Governance: http://systemd.cn/docs/GOVERNANCE/
- Hacking on systemd: http://systemd.cn/docs/HACKING/
- Home Directories: http://systemd.cn/docs/HOME_DIRECTORY/
- Inhibitor Locks: http://systemd.cn/docs/INHIBITOR_LOCKS/
- Initrd Interface: http://systemd.cn/docs/INITRD_INTERFACE/
- Journal Export Formats: http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/
- Journal File Format: http://systemd.cn/docs/JOURNAL_FILE_FORMAT/
- Journal Message Catalogs: http://systemd.cn/docs/CATALOG/
- JSON Group Records: http://systemd.cn/docs/GROUP_RECORD/
- JSON User Records: http://systemd.cn/docs/USER_RECORD/
- Known Environment Variables: http://systemd.cn/docs/ENVIRONMENT/
- Locking Block Device Access: http://systemd.cn/docs/BLOCK_DEVICE_LOCKING/
- Minimal Builds: http://systemd.cn/docs/MINIMAL_BUILDS/
- My Service Can't Get Realtime!: http://systemd.cn/docs/MY_SERVICE_CANT_GET_REALTIME/
- Native Journal Protocol: http://systemd.cn/docs/JOURNAL_NATIVE_PROTOCOL/
- New Control Group Interfaces: http://systemd.cn/docs/CONTROL_GROUP_INTERFACE/
- Notes for Translators: http://systemd.cn/docs/TRANSLATORS/
- Password Agents: http://systemd.cn/docs/PASSWORD_AGENTS/
- Pax Controla Groupiana: http://systemd.cn/docs/PAX_CONTROL_GROUPS/
- Portability and Stability: http://systemd.cn/docs/PORTABILITY_AND_STABILITY/
- Portable Services Introduction: http://systemd.cn/docs/PORTABLE_SERVICES/
- Porting systemd To New Distributions: http://systemd.cn/docs/DISTRO_PORTING/
- Porting to New Architectures: http://systemd.cn/docs/PORTING_TO_NEW_ARCHITECTURES/
- Predictable Network Interface Names: http://systemd.cn/docs/PREDICTABLE_INTERFACE_NAMES/
- Presets: http://systemd.cn/docs/PRESET/
- Project IDs for Disk Quotas on Exec Directories: http://systemd.cn/docs/DISK-QUOTAS-PROJECTIDS/
- Random Seeds: http://systemd.cn/docs/RANDOM_SEEDS/
- Reporting of Security Vulnerabilities: http://systemd.cn/docs/SECURITY/
- Resource Pressure Handling: http://systemd.cn/docs/PRESSURE/
- Running Services After the Network Is Up: http://systemd.cn/docs/NETWORK_ONLINE/
- Safely Building Images: http://systemd.cn/docs/BUILDING_IMAGES/
- Socket Activation with Popular Daemons: http://systemd.cn/docs/DAEMON_SOCKET_ACTIVATION/
- Steps to a Successful Release: http://systemd.cn/docs/RELEASE/
- Storage Daemons for the Root File System: http://systemd.cn/docs/ROOT_STORAGE_DAEMONS/
- systemd Community Conduct Guidelines: http://systemd.cn/docs/CODE_OF_CONDUCT/
- systemd Coredump Handling: http://systemd.cn/docs/COREDUMP/
- systemd File Hierarchy Requirements: http://systemd.cn/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS/
- systemd Optimizations: http://systemd.cn/docs/OPTIMIZATIONS/
- systemd Repository Architecture: http://systemd.cn/docs/ARCHITECTURE/
- systemd-boot UEFI Boot Manager: http://systemd.cn/docs/BOOT/
- systemd-homed and JSON User/Group Record Support in Desktop Environments: http://systemd.cn/docs/USERDB_AND_DESKTOPS/
- systemd-resolved and VPNs: http://systemd.cn/docs/RESOLVED-VPNS/
- Testing systemd Using Sanitizers: http://systemd.cn/docs/TESTING_WITH_SANITIZERS/
- The Case for the /usr Merge: http://systemd.cn/docs/THE_CASE_FOR_THE_USR_MERGE/
- Tips And Tricks: http://systemd.cn/docs/TIPS_AND_TRICKS/
- User Record Blob Directories: http://systemd.cn/docs/USER_RECORD_BLOB_DIRS/
- User/Group Name Syntax: http://systemd.cn/docs/USER_NAMES/
- User/Group Record Lookup API via Varlink: http://systemd.cn/docs/USER_GROUP_API/
- Users, Groups, UIDs and GIDs on systemd Systems: http://systemd.cn/docs/UIDS-GIDS/
- Using /tmp/ and /var/tmp/ Safely: http://systemd.cn/docs/TEMPORARY_DIRECTORIES/
- Varlink API Style: http://systemd.cn/docs/VARLINK/
- VM Interface: http://systemd.cn/docs/VM_INTERFACE/
- What Settings Are Currently Available For Transient Units?: http://systemd.cn/docs/TRANSIENT-SETTINGS/
- Writing Desktop Environments: http://systemd.cn/docs/WRITING_DESKTOP_ENVIRONMENTS/
- Writing Display Managers: http://systemd.cn/docs/WRITING_DISPLAY_MANAGERS/
- Writing Network Configuration Managers: http://systemd.cn/docs/WRITING_NETWORK_CONFIGURATION_MANAGERS/
- Writing Resolver Clients: http://systemd.cn/docs/WRITING_RESOLVER_CLIENTS/
- Writing syslog Daemons Which Cooperate Nicely With systemd: http://systemd.cn/docs/SYSLOG/
- Writing VM and Container Managers: http://systemd.cn/docs/WRITING_VM_AND_CONTAINER_MANAGERS/


# 挂载点可用性要求

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.