diff --git a/docs/BOOT_LOADER_INTERFACE.md b/docs/BOOT_LOADER_INTERFACE.md index e1ba815d34..6084fe2a2a 100644 --- a/docs/BOOT_LOADER_INTERFACE.md +++ b/docs/BOOT_LOADER_INTERFACE.md @@ -142,3 +142,11 @@ names for them in UIs. 6. If a boot menu entry encapsulates a reboot into EFI firmware setup feature, it should use the identifier `reboot-to-firmware-setup` (or `auto-reboot-to-firmware-setup` in case it is automatically discovered). + +## Links + +[Boot Loader Specification](https://systemd.io/BOOT_LOADER_INTERFACE)
+[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)
+[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
+[bootctl(1)](https://www.freedesktop.org/software/systemd/man/bootctl.html)
+[systemd-gpt-auto-generator(8)](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html) diff --git a/docs/BOOT_LOADER_SPECIFICATION.md b/docs/BOOT_LOADER_SPECIFICATION.md index 13ceaa8482..514b8cd11a 100644 --- a/docs/BOOT_LOADER_SPECIFICATION.md +++ b/docs/BOOT_LOADER_SPECIFICATION.md @@ -55,14 +55,14 @@ functionality. Here's why we think that it is not enough for our uses: Everything described below is located on a placeholder file system `$BOOT`. The installer program should pick `$BOOT` according to the following rules: -* On disks with MBR disk labels - * If the OS is installed on a disk with MBR disk label, and a partition with the MBR type id of 0xEA already exists it should be used as `$BOOT`. - * Otherwise, if the OS is installed on a disk with MBR disk label, a new partition with MBR type id of 0xEA shall be created, of a suitable size (let's say 500MB), and it should be used as `$BOOT`. -* On disks with GPT disk labels - * If the OS is installed on a disk with GPT disk label, and a partition with the GPT type GUID of `bc13c2ff-59e6-4262-a352-b275fd6f7172` already exists, it should be used as `$BOOT`. - * Otherwise, if the OS is installed on a disk with GPT disk label, and an ESP partition (i.e. with the GPT type UID of `c12a7328-f81f-11d2-ba4b-00a0c93ec93b`) already exists and is large enough (let's say 250MB) and otherwise qualifies, it should be used as `$BOOT`. - * Otherwise, if the OS is installed on a disk with GPT disk label, and if the ESP partition already exists but is too small, a new suitably sized (let's say 500MB) partition with GPT type GUID of `bc13c2ff-59e6-4262-a352-b275fd6f7172` shall be created and it should be used as `$BOOT`. - * Otherwise, if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and should be used as `$BOOT`. +* On disks with an MBR partition table: + * If the OS is installed on a disk with an MBR partition table, and a partition with the type id of 0xEA already exists it should be used as `$BOOT`. + * Otherwise, if the OS is installed on a disk with an MBR partition table, a new partition with type id of 0xEA shall be created, of a suitable size (let's say 500MB), and it should be used as `$BOOT`. +* On disks with GPT (GUID Partition Table) + * If the OS is installed on a disk with GPT, and an Extended Boot Loader Partition or XBOOTLDR partition for short, i.e. a partition with GPT type GUID of `bc13c2ff-59e6-4262-a352-b275fd6f7172`, already exists, it should be used as `$BOOT`. + * Otherwise, if the OS is installed on a disk with GPT, and an EFI System Partition or ESP for short, i.e. a partition with GPT type UID of `c12a7328-f81f-11d2-ba4b-00a0c93ec93b`) already exists and is large enough (let's say 250MB) and otherwise qualifies, it should be used as `$BOOT`. + * Otherwise, if the OS is installed on a disk with GPT, and if the ESP partition already exists but is too small, a new suitably sized (let's say 500MB) XBOOTLDR partition shall be created and used as `$BOOT`. + * Otherwise, if the OS is installed on a disk with GPT, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and used as `$BOOT`. This placeholder file system shall be determined during _installation time_, and an fstab entry may be created. It should be mounted to either `/boot/` or `/efi/`. Additional locations like `/boot/efi/`, with `/boot/` being a separate file system, might be supported by implementations. This is not recommended because the mounting of `$BOOT` is then dependent on and requires the mounting of the intermediate file system. @@ -234,5 +234,9 @@ There are a couple of items that are out of focus for this specification: ## Links +[GUID Partition Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)
+[Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE)
+[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)
[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
-[bootctl(1)](https://www.freedesktop.org/software/systemd/man/bootctl.html) +[bootctl(1)](https://www.freedesktop.org/software/systemd/man/bootctl.html)
+[systemd-gpt-auto-generator(8)](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html) diff --git a/man/environment.d.xml b/man/environment.d.xml index 69c156aacb..17c2c505ed 100644 --- a/man/environment.d.xml +++ b/man/environment.d.xml @@ -36,11 +36,11 @@ Description - The environment.d directories contain a list of "global" environment - variable assignments for the user environment. + The environment.d directories contain a list of environment variable + assignments for services started by the systemd user instance. systemd-environment-d-generator8 - parses them and updates the environment exported by the systemd user instance to the services it - starts. + parses them and updates the environment exported by the systemd user instance. See below for an + discussion of which processes inherit those variables. It is recommended to use numerical prefixes for file names to simplify ordering. @@ -89,6 +89,33 @@ + + Applicability + + Environment variables exported by the user manager (systemd --user instance + started in the user@uid.service system service) apply to + any services started by that manager. In particular, this may include services which run user shells. For + example in the Gnome environment, the graphical terminal emulator runs as the + gnome-terminal-server.service user unit, which in turn runs the user shell, so that + shell will inherit environment variables exported by the user manager. For other instances of the shell, + not launched by the user manager, the environment they inherit is defined by the program that starts + them. Hint: in general, + systemd.service5 + units contain programs launched by systemd, and + systemd.scope5 + units contain programs launched by something else. + + Specifically, for ssh logins, the + sshd8 + service builds an environment that is a combination of variables forwarded from the remote system and + defined by sshd, see the discussion in + ssh1. + A graphical display session will have an analogous mechanism to define the environment. Note that some + managers query the systemd user instance for the exported environment and inject this configuration into + programs they start, using systemctl show-environment or the underlying D-Bus call. + + + See Also diff --git a/man/rules/meson.build b/man/rules/meson.build index 98316b33b2..5fe6df6272 100644 --- a/man/rules/meson.build +++ b/man/rules/meson.build @@ -670,8 +670,11 @@ manpages = [ ['systemd-backlight@.service', '8', ['systemd-backlight'], 'ENABLE_BACKLIGHT'], ['systemd-binfmt.service', '8', ['systemd-binfmt'], 'ENABLE_BINFMT'], ['systemd-bless-boot-generator', '8', [], 'ENABLE_EFI'], - ['systemd-bless-boot.service', '8', [], 'ENABLE_EFI'], - ['systemd-boot-check-no-failures.service', '8', [], ''], + ['systemd-bless-boot.service', '8', ['systemd-bless-boot'], 'ENABLE_EFI'], + ['systemd-boot-check-no-failures.service', + '8', + ['systemd-boot-check-no-failures'], + ''], ['systemd-boot-system-token.service', '8', [], 'ENABLE_EFI'], ['systemd-boot', '7', ['sd-boot'], 'ENABLE_EFI'], ['systemd-cat', '1', [], ''], diff --git a/man/systemd-bless-boot.service.xml b/man/systemd-bless-boot.service.xml index cd5e9ac019..4a45560a8c 100644 --- a/man/systemd-bless-boot.service.xml +++ b/man/systemd-bless-boot.service.xml @@ -18,6 +18,7 @@ systemd-bless-boot.service + systemd-bless-boot Mark current boot process as successful diff --git a/man/systemd-boot-check-no-failures.service.xml b/man/systemd-boot-check-no-failures.service.xml index d6d587f9ca..8509fa633e 100644 --- a/man/systemd-boot-check-no-failures.service.xml +++ b/man/systemd-boot-check-no-failures.service.xml @@ -18,6 +18,7 @@ systemd-boot-check-no-failures.service + systemd-boot-check-no-failures verify that the system booted up cleanly diff --git a/man/user@.service.xml b/man/user@.service.xml index 81a6fef4ba..f4603df073 100644 --- a/man/user@.service.xml +++ b/man/user@.service.xml @@ -49,7 +49,7 @@ User processes may be started by the user@.service instance, in which case they will be part of that unit in the system hierarchy. They may also be started elsewhere, for example by - sshd8 or a + sshd8 or a display manager like gdm, in which case they form a .scope unit (see systemd.scope5). Both user@UID.service and the scope units are @@ -142,7 +142,7 @@ Control group /: … User with UID 1000 is logged in using gdm (session-4.scope) and - ssh1 + ssh1 (session-19.scope), and also has a user manager instance running (user@1000.service). User with UID 1001 is logged in using ssh (session-20.scope) and diff --git a/man/userdbctl.xml b/man/userdbctl.xml index 69cd3fc067..606ce673b5 100644 --- a/man/userdbctl.xml +++ b/man/userdbctl.xml @@ -228,7 +228,7 @@ The userdbctl tool may be used to make the list of SSH authorized keys possibly contained in a user record available to the SSH daemon for authentication. For that configure the following in sshd_config5: + project='die-net'>sshd_config5: … AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u diff --git a/meson.build b/meson.build index 074e80ff13..c8f6482e4a 100644 --- a/meson.build +++ b/meson.build @@ -21,11 +21,13 @@ libudev_version = '1.6.17' # names, sometimes. Not all variables are included in every # set. Ugh, ugh, ugh! conf = configuration_data() -conf.set('PROJECT_VERSION', meson.project_version()) +conf.set('PROJECT_VERSION', meson.project_version(), + description : 'Numerical project version (used where a simple number is expected)') substs = configuration_data() substs.set('PROJECT_URL', 'https://www.freedesktop.org/wiki/Software/systemd') -substs.set('PROJECT_VERSION', meson.project_version()) +substs.set('PROJECT_VERSION', meson.project_version(), + description : 'Numerical project version (used where a simple number is expected)') # This is to be used instead of meson.source_root(), as the latter will return # the wrong result when systemd is being built as a meson subproject diff --git a/src/version/version.h.in b/src/version/version.h.in index 9f82d905a7..4219dce83a 100644 --- a/src/version/version.h.in +++ b/src/version/version.h.in @@ -1 +1,8 @@ +/* Detailed project version that includes git commit when not built from a release. + * Use this in preference to PROJECT_VERSION, with the following exceptions: + * - where a simplified form is expected for compatiblity, for example + * 'udevadm version', + * - where a simplified machine-parsable form is more useful, for example + * pkgconfig files and version information written to binary files. + */ #define GIT_VERSION "@VCS_TAG@"