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/ # 恢复出厂设置 In various scenarios it is important to be able to reset operating systems back into a "factory state", i.e. where all state, user data and configuration is reset so that it resembles the system state when it was originally shipped. systemd natively supports a concept of factory reset, that can both act as a specific implementation for UEFI based systems, as well as a series of hook points and a template for implementations on other systems. Factory reset always takes place during early boot, i.e. from a well-defined "clean" state. Factory reset operations may be requested from one boot to be executed on the next. Specifically, the following concepts are available: * The `factory-reset.target` unit may be used to request a factory reset operation and trigger a reboot in order to execute it. It by default executes three services: `systemd-factory-reset-request.service`, `systemd-tpm2-clear.service` and `systemd-factory-reset-reboot.service`. * The [`systemd-factory-reset-request.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-factory-reset-request.service.html) unit is typically invoked via `factory-reset.target`. It requests a factory reset operation for the next boot by setting the `FactoryResetRequest` EFI variable. The EFI variable contains information about the requesting OS, so that multi-boot scenarios are somewhat covered. * The [`systemd-tpm2-clear.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-tpm2-clear.service.html) unit can request a TPM2 clear operation from the firmware on the next boot. It is also invoked via `factory-reset.target`. UEFI firmwares that support TPMs will ask the user for confirmation and then reset the TPM, invalidating all prior keys associated with the security chip and generating a new seed key. * The [`systemd-factory-reset-reboot.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-factory-reset-reboot.service.html) unit automatically reboots the system as part of `factory-reset.target`. It is ordered after `systemd-tpm2-clear.service` and `systemd-factory-reset-request.service` in order to initiate the reboot that is supposed to execute the factory reset operations. * The `factory-reset-now.target` unit is started at boot whenever a factory reset is requested for the boot. A factory reset may be requested via a kernel command line option (`systemd.factory_reset=1`) or via the UEFI variable `FactoryResetRequest` (see above). The `systemd-factory-reset-generator` unit generator checks both these conditions and adds `factory-reset-now.target` to the boot transaction, already in the initial RAM disk (initrd). * The [`systemd-factory-reset-complete.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-factory-reset-complete.service.html) unit is invoked after `factory-reset-now.target` and marks the factory reset operation as complete. The boot process then may continue. * The [`systemd-repart`](https://www.freedesktop.org/software/systemd/man/latest/systemd-repart.html) tool can take the factory reset logic into account. Either on explicit request via the `--factory-reset=` logic, or automatically derived from the aforementioned kernel command line switch and EFI variable. When invoked for factory reset it will securely erase all partitions marked for that via the `FactoryReset=` setting in its partition definition files. Once that is complete it will execute the usual setup operation, i.e. format new partitions again. * The [`systemd-logind.service(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html) unit supports automatically binding factory reset to special keypresses (typically long presses), see the [`logind.conf(5)`](https://www.freedesktop.org/software/systemd/man/latest/logind.conf.html) man page. * The [`systemd-factory-reset`](https://www.freedesktop.org/software/systemd/man/latest/systemd-factory-reset.html) tool can be used to query the current state of the factory request mechanism, i.e. whether a factory reset is currently being executed, or if one has been requested for the next boot. * The `/run/systemd/io.systemd.FactoryReset` Varlink service provides two IPC APIs for working with factory reset: it permits querying whether the local system supports requesting a factory reset by starting `factory-reset.target`. This may be used by UIs to hide or show in the UI an interface to request a factory reset. The Varlink IPC service also reports the current factory reset state, much like the `systemd-factory-reset` tool mentioned above. This may be used by various early boot services that potentially intent to reset system state during a factory reset operation. ## Exposure in the UI If a graphical UI shall expose a factory reset operation it should first check if requesting a factory reset is supported at all via the Varlink service mentioned above. Once a factory reset shall be executed it shall ask for activation of the `factory-reset.target` unit. Alternatively, `systemd-logind.service`'s hotkey support may be used, for example to request factory reset if the reboot button is pressed for a long time. ## Support for non-UEFI Systems The above is a relatively bespoke solution for EFI systems. It uses EFI variables as stateful memory to request the factory reset on the next boot. On non-EFI systems, a different mechanism should be devised. A service requesting the factory request can then be plugged into `factory-reset.target`. At boot the request should then be fed back to the booted kernel via the `systemd.factory_reset=1` kernel command line option, in order to execute the reset operation. ## Support for Resetting other Resources than Partitions + TPM By default a factory reset implemented with systemd's tools can reset/erase partitions (via `systemd-repart`, see above) and reset the TPM (via `systemd-tpm2-clear.service`, see above). In some cases other resources shall be reset/erased too. To support that, define your own service and plug it into `factory-reset-now.target`, ensuring it is ordered before that. ## Factory Reset via Boot Menu Factory reset can also be requested via the boot menu. A simple factory reset (that does not touch the TPM) at boot can be requested via a boot menu item containing the `systemd.factory_reset=1` kernel command line option. A more comprehensive factory reset operation (that also erases the TPM) can be requested by booting with `rd.systemd.unit=factory-reset.target`. Note that the latter will require one reboot (required since that's how TPM resets work), while the former will reset state and continue running without an additional reboot.