Releases: systemd/systemd
systemd v251
systemd System and Service Manager
CHANGES WITH 251:
Backwards-incompatible changes:
* The minimum kernel version required has been bumped from 3.13 to 4.15,
and CLOCK_BOOTTIME is now assumed to always exist.
* C11 with GNU extensions (aka "gnu11") is now used to build our
components. Public API headers are still restricted to ISO C89.
* In v250, a systemd-networkd feature that automatically configures
routes to addresses specified in AllowedIPs= was added and enabled by
default. However, this causes network connectivity issues in many
existing setups. Hence, it has been disabled by default since
systemd-stable 250.3. The feature can still be used by explicitly
configuring RouteTable= setting in .netdev files.
* Jobs started via StartUnitWithFlags() will no longer return 'skipped'
when a Condition*= check does not succeed, restoring the JobRemoved
signal to the behaviour it had before v250.
* The org.freedesktop.portable1 methods GetMetadataWithExtensions() and
GetImageMetadataWithExtensions() have been fixed to provide an extra
return parameter, containing the actual extension release metadata.
The current implementation was judged to be broken and unusable, and
thus the usual procedure of adding a new set of methods was skipped,
and backward compatibility broken instead on the assumption that
nobody can be affected given the current state of this interface.
* All kernels supported by systemd mix RDRAND (or similar) into the
entropy pool at early boot. This means that on those systems, even if
/dev/urandom is not yet initialized, it still returns bytes that that
are at least as high quality as RDRAND. For that reason, we no longer
have reason to invoke RDRAND from systemd itself, which has
historically been a source of bugs. Furthermore, kernels β₯5.6 provide
the getrandom(GRND_INSECURE) interface for returning random bytes
before the entropy pool is initialized without warning into kmsg,
which is what we attempt to use if available. systemd's direct usage
of RDRAND has been removed. x86 systems β₯Broadwell that are running
an older kernel may experience kmsg warnings that were not seen with
250. For newer kernels, non-x86 systems, or older x86 systems, there
should be no visible changes.
* sd-boot will now measure the kernel command line into TPM PCR 12
rather than PCR 8. This improves usefulness of the measurements on
systems where sd-boot is chainloaded from Grub. Grub measures all
commands its executes into PCR 8, which makes it very hard to use
reasonably, hence separate ourselves from that and use PCR 12
instead, which is what certain Ubuntu editions already do. To retain
compatibility with systems running older systemd systems a new meson
option 'efi-tpm-pcr-compat' has been added (which defaults to false).
If enabled, the measurement is done twice: into the new-style PCR 12
*and* the old-style PCR 8. It's strongly advised to migrate all users
to PCR 12 for this purpose in the long run, as we intend to remove
this compatibility feature in two year's time.
* busctl capture now writes output in the newer pcapng format instead
of pcap.
* An udev rule that imported hwdb matches for USB devices with
lowercase hexadecimal vendor/product ID digits was added in systemd
250. This has been reverted, since uppercase hexadecimal digits are
supposed to be used, and we already had a rule that with the
appropriate match.
Users might need to adjust their local hwdb entries.
* arch_prctl(2) has been moved to the @default set in the syscall filters
(as exposed via the SystemCallFilter= setting in service unit files).
It is apparently used by the linker now.
* The tmpfiles entries that create the /run/systemd/netif directory and
its subdirectories were moved from tmpfiles.d/systemd.conf to
tmpfiles.d/systemd-network.conf.
Users might need to adjust their files that override tmpfiles.d/systemd.conf
to account for this change.
* The requirement for Portable Services images to contain a well-formed
os-release file (i.e.: contain at least an ID field) is now enforced.
This applies to base images and extensions, and also to systemd-sysext.
Changes in the Boot Loader Specification, kernel-install and sd-boot:
* kernel-install's and bootctl's Boot Loader Specification Type #1
entry generation logic has been reworked. The user may now pick
explicitly by which "token" string to name the installation's boot
entries, via the new /etc/kernel/entry-token file or the new
--entry-token= switch to bootctl. By default β as before β the
entries are named after the local machine ID. However, in "golden
image" environments, where the machine ID shall be initialized on
first boot (as opposed to at installation time before first boot) the
machine ID will not be available at build time. In this case the
--entry-token= switch to bootctl (or the /etc/kernel/entry-token
file) may be used to override the "token" for the entries, for
example the IMAGE_ID= or ID= fields from /etc/os-release. This will
make the OS images independent of any machine ID, and ensure that the
images will not carry any identifiable information before first boot,
but on the other hand means that multiple parallel installations of
the very same image on the same disk cannot be supported.
Summary: if you are building golden images that shall acquire
identity information exclusively on first boot, make sure to both
remove /etc/machine-id *and* to write /etc/kernel/entry-token to the
value of the IMAGE_ID= or ID= field of /etc/os-release or another
suitable identifier before deploying the image.
* The Boot Loader Specification has been extended with
/loader/entries.srel file located in the EFI System Partition (ESP)
that disambiguates the format of the entries in the /loader/entries/
directory (in order to discern them from incompatible uses of this
directory by other projects). For entries that follow the
Specification, the string "type1" is stored in this file.
bootctl will now write this file automatically when installing the
systemd-boot boot loader.
* kernel-install supports a new initrd_generator= setting in
/etc/kernel/install.conf, that is exported as
$KERNEL_INSTALL_INITRD_GENERATOR to kernel-install plugins. This
allows choosing different initrd generators.
* kernel-install will now create a "staging area" (an initially-empty
directory to gather files for a Boot Loader Specification Type #1
entry). The path to this directory is exported as
$KERNEL_INSTALL_STAGING_AREA to kernel-install plugins, which should
drop files there instead of writing them directly to the final
location. kernel-install will move them when all files have been
prepared successfully.
* New option sort-key= has been added to the Boot Loader Specification
to override the sorting order of the entries in the boot menu. It is
read by sd-boot and bootctl, and will be written by kernel-install,
with the default value of IMAGE_ID= or ID= fields from
os-release. Together, this means that on multiboot installations,
entries should be grouped and sorted in a predictable way.
* The sort order of boot entries has been updated: entries which have
the new field sort-key= are sorted by it first, and all entries
without it are ordered later. After that, entries are sorted by
version so that newest entries are towards the beginning of the list.
* The kernel-install tool gained a new 'inspect' verb which shows the
paths and other settings used.
* sd-boot can now optionally beep when the menu is shown and menu
entries are selected, which can be useful on machines without a
working display. (Controllable via a loader.conf setting.)
* The --make-machine-id-directory= switch to bootctl has been replaced
by --make-entry-directory=, given that the entry directory is not
necessarily named after the machine ID, but after some other suitable
ID as selected via --entry-token= described above. The old name of
the option is still understood to maximize compatibility.
* 'bootctl list' gained support for a new --json= switch to output boot
menu entries in JSON format.
* 'bootctl is-installed' now supports the --graceful, and various verbs
omit output with the new option --quiet.
Changes in systemd-homed:
* Starting with v250 systemd-homed uses UID/GID mapping on the mounts
of activated home directories it manages (if the kernel and selected
file systems support it). So far it mapped three UID ranges: the
range from 0β¦60000, the user's own UID, and the range 60514β¦65534,
leaving everything else unmapped (in other words, the 16bit UID range
...
v251-rc3
Backwards-incompatible changes:
* The minimum kernel version required has been bumped from 3.13 to 4.15,
and CLOCK_BOOTTIME is now assumed to always exist.
* C11 with GNU extensions (aka "gnu11") is now used to build our
components. Public API headers are still restricted to ISO C89.
* In v250, a systemd-networkd feature that automatically configures
routes to addresses specified in AllowedIPs= was added and enabled by
default. However, this causes network connectivity issues in many
existing setups. Hence, it has been disabled by default since
systemd-stable 250.3. The feature can still be used by explicitly
configuring RouteTable= setting in .netdev files.
* Jobs started via StartUnitWithFlags() will no longer return 'skipped'
when a Condition*= check does not succeed, restoring the JobRemoved
signal to the behaviour it had before v250.
* The org.freedesktop.portable1 methods GetMetadataWithExtensions() and
GetImageMetadataWithExtensions() have been fixed to provide an extra
return parameter, containing the actual extension release metadata.
The current implementation was judged to be broken and unusable, and
thus the usual procedure of adding a new set of methods was skipped,
and backward compatibility broken instead on the assumption that
nobody can be affected given the current state of this interface.
* All kernels supported by systemd mix RDRAND (or similar) into the
entropy pool at early boot. This means that on those systems, even if
/dev/urandom is not yet initialized, it still returns bytes that that
are at least as high quality as RDRAND. For that reason, we no longer
have reason to invoke RDRAND from systemd itself, which has
historically been a source of bugs. Furthermore, kernels β₯5.6 provide
the getrandom(GRND_INSECURE) interface for returning random bytes
before the entropy pool is initialized without warning into kmsg,
which is what we attempt to use if available. systemd's direct usage
of RDRAND has been removed. x86 systems β₯Broadwell that are running
an older kernel may experience kmsg warnings that were not seen with
250. For newer kernels, non-x86 systems, or older x86 systems, there
should be no visible changes.
* sd-boot will now measure the kernel command line into TPM PCR 12
rather than PCR 8. This improves usefulness of the measurements on
systems where sd-boot is chainloaded from Grub. Grub measures all
commands its executes into PCR 8, which makes it very hard to use
reasonably, hence separate ourselves from that and use PCR 12
instead, which is what certain Ubuntu editions already do. To retain
compatibility with systems running older systemd systems a new meson
option 'efi-tpm-pcr-compat' has been added (which defaults to false).
If enabled, the measurement is done twice: into the new-style PCR 12
*and* the old-style PCR 8. It's strongly advised to migrate all users
to PCR 12 for this purpose in the long run, as we intend to remove
this compatibility feature in two year's time.
* busctl capture now writes output in the newer pcapng format instead
of pcap.
* An udev rule that imported hwdb matches for USB devices with
lowercase hexadecimal vendor/product ID digits was added in systemd
250. This has been reverted, since uppercase hexadecimal digits are
supposed to be used, and we already had a rule that with the
appropriate match.
Users might need to adjust their local hwdb entries.
* arch_prctl(2) has been moved to the @default set in the syscall filters
(as exposed via the SystemCallFilter= setting in service unit files).
It is apparently used by the linker now.
* The tmpfiles entries that create the /run/systemd/netif directory and
its subdirectories were moved from tmpfiles.d/systemd.conf to
tmpfiles.d/systemd-network.conf.
Users might need to adjust their files that override tmpfiles.d/systemd.conf
to account for this change.
Changes in the Boot Loader Specification, kernel-install and sd-boot:
* kernel-install's and bootctl's Boot Loader Specification Type #1
entry generation logic has been reworked. The user may now pick
explicitly by which "token" string to name the installation's boot
entries, via the new /etc/kernel/entry-token file or the new
--entry-token= switch to bootctl. By default β as before β the
entries are named after the local machine ID. However, in "golden
image" environments, where the machine ID shall be initialized on
first boot (as opposed to at installation time before first boot) the
machine ID will not be available at build time. In this case the
--entry-token= switch to bootctl (or the /etc/kernel/entry-token
file) may be used to override the "token" for the entries, for
example the IMAGE_ID= or ID= fields from /etc/os-release. This will
make the OS images independent of any machine ID, and ensure that the
images will not carry any identifiable information before first boot,
but on the other hand means that multiple parallel installations of
the very same image on the same disk cannot be supported.
Summary: if you are building golden images that shall acquire
identity information exclusively on first boot, make sure to both
remove /etc/machine-id *and* to write /etc/kernel/entry-token to the
value of the IMAGE_ID= or ID= field of /etc/os-release or another
suitable identifier before deploying the image.
* The Boot Loader Specification has been extended with
/loader/entries.srel file located in the EFI System Partition (ESP)
that disambiguates the format of the entries in the /loader/entries/
directory (in order to discern them from incompatible uses of this
directory by other projects). For entries that follow the
Specification, the string "type1" is stored in this file.
bootctl will now write this file automatically when installing the
systemd-boot boot loader.
* kernel-install supports a new initrd_generator= setting in
/etc/kernel/install.conf, that is exported as
$KERNEL_INSTALL_INITRD_GENERATOR to kernel-install plugins. This
allows choosing different initrd generators.
* kernel-install will now create a "staging area" (an initially-empty
directory to gather files for a Boot Loader Specification Type #1
entry). The path to this directory is exported as
$KERNEL_INSTALL_STAGING_AREA to kernel-install plugins, which should
drop files there instead of writing them directly to the final
location. kernel-install will move them when all files have been
prepared successfully.
* New option sort-key= has been added to the Boot Loader Specification
to override the sorting order of the entries in the boot menu. It is
read by sd-boot and bootctl, and will be written by kernel-install,
with the default value of IMAGE_ID= or ID= fields from
os-release. Together, this means that on multiboot installations,
entries should be grouped and sorted in a predictable way.
* The sort order of boot entries has been updated: entries which have
the new field sort-key= are sorted by it first, and all entries
without it are ordered later. After that, entries are sorted by
version so that newest entries are towards the beginning of the list.
* The kernel-install tool gained a new 'inspect' verb which shows the
paths and other settings used.
* sd-boot can now optionally beep when the menu is shown and menu
entries are selected, which can be useful on machines without a
working display. (Controllable via a loader.conf setting.)
* The --make-machine-id-directory= switch to bootctl has been replaced
by --make-entry-directory=, given that the entry directory is not
necessarily named after the machine ID, but after some other suitable
ID as selected via --entry-token= described above. The old name of
the option is still understood to maximize compatibility.
* 'bootctl list' gained support for a new --json= switch to output boot
menu entries in JSON format.
* 'bootctl is-installed' now supports the --graceful, and various verbs
omit output with the new option --quiet.
Changes in systemd-homed:
* Starting with v250 systemd-homed uses UID/GID mapping on the mounts
of activated home directories it manages (if the kernel and selected
file systems support it). So far it mapped three UID ranges: the
range from 0β¦60000, the user's own UID, and the range 60514β¦65534,
leaving everything else unmapped (in other words, the 16bit UID range
is mapped almost fully, with the exception of the UID subrange used
for systemd-homed users, with one exception: the user's own UID).
Unmapped UIDs may not be used for file ownership in the home
directory β any chown() attempts with them will fail. With this
re...
v251-rc2
Backwards-incompatible changes:
-
The minimum kernel version required has been bumped from 3.13 to 4.15,
and CLOCK_BOOTTIME is now assumed to always exist. -
C11 with GNU extensions (aka "gnu11") is now used to build our
components. Public API headers are still restricted to ISO C89. -
In v250, a systemd-networkd feature that automatically configures
routes to addresses specified in AllowedIPs= was added and enabled by
default. However, this causes network connectivity issues in many
existing setups. Hence, it has been disabled by default since
systemd-stable 250.3. The feature can still be used by explicitly
configuring RouteTable= setting in .netdev files. -
Jobs started via StartUnitWithFlags() will no longer return 'skipped'
when a Condition*= check does not succeed, restoring the JobRemoved
signal to the behaviour it had before v250. -
The org.freedesktop.portable1 methods GetMetadataWithExtensions() and
GetImageMetadataWithExtensions() have been fixed to provide an extra
return parameter, containing the actual extension release metadata.
The current implementation was judged to be broken and unusable, and
thus the usual procedure of adding a new set of methods was skipped,
and backward compatibility broken instead on the assumption that
nobody can be affected given the current state of this interface. -
All kernels supported by systemd mix RDRAND (or similar) into the
entropy pool at early boot. This means that on those systems, even if
/dev/urandom is not yet initialized, it still returns bytes that that
are at least as high quality as RDRAND. For that reason, we no longer
have reason to invoke RDRAND from systemd itself, which has
historically been a source of bugs. Furthermore, kernels β₯5.6 provide
the getrandom(GRND_INSECURE) interface for returning random bytes
before the entropy pool is initialized without warning into kmsg,
which is what we attempt to use if available. systemd's direct usage
of RDRAND has been removed. x86 systems β₯Broadwell that are running
an older kernel may experience kmsg warnings that were not seen with
250. For newer kernels, non-x86 systems, or older x86 systems, there
should be no visible changes. -
sd-boot will now measure the kernel command line into TPM PCR 12
rather than PCR 8. This improves usefulness of the measurements on
systems where sd-boot is chainloaded from Grub. Grub measures all
commands its executes into PCR 8, which makes it very hard to use
reasonably, hence separate ourselves from that and use PCR 12
instead, which is what certain Ubuntu editions already do. To retain
compatibility with systems running older systemd systems a new meson
option 'efi-tpm-pcr-compat' has been added (which defaults to false).
If enabled, the measurement is done twice: into the new-style PCR 12
and the old-style PCR 8. It's strongly advised to migrate all users
to PCR 12 for this purpose in the long run, as we intend to remove
this compatibility feature in two year's time. -
busctl capture now writes output in the newer pcapng format instead
of pcap. -
An udev rule that imported hwdb matches for USB devices with
lowercase hexadecimal vendor/product ID digits was added in systemd
250. This has been reverted, since uppercase hexadecimal digits are
supposed to be used, and we already had a rule that with the
appropriate match.Users might need to adjust their local hwdb entries.
-
arch_prctl(2) has been moved to the @default set in the syscall filters
(as exposed via the SystemCallFilter= setting in service unit files).
It is apparently used by the linker now. -
The tmpfiles entries that create the /run/systemd/netif directory and
its subdirectories were moved from tmpfiles.d/systemd.conf to
tmpfiles.d/systemd-network.conf.Users might need to adjust their files that override tmpfiles.d/systemd.conf
to account for this change.
Changes in the Boot Loader Specification, kernel-install and sd-boot:
-
kernel-install's and bootctl's Boot Loader Specification Type #1
entry generation logic has been reworked. The user may now pick
explicitly by which "token" string to name the installation's boot
entries, via the new /etc/kernel/entry-token file or the new
--entry-token= switch to bootctl. By default β as before β the
entries are named after the local machine ID. However, in "golden
image" environments, where the machine ID shall be initialized on
first boot (as opposed to at installation time before first boot) the
machine ID will not be available at build time. In this case the
--entry-token= switch to bootctl (or the /etc/kernel/entry-token
file) may be used to override the "token" for the entries, for
example the IMAGE_ID= or ID= fields from /etc/os-release. This will
make the OS images independent of any machine ID, and ensure that the
images will not carry any identifiable information before first boot,
but on the other hand means that multiple parallel installations of
the very same image on the same disk cannot be supported.Summary: if you are building golden images that shall acquire
identity information exclusively on first boot, make sure to both
remove /etc/machine-id and to write /etc/kernel/entry-token to the
value of the IMAGE_ID= or ID= field of /etc/os-release or another
suitable identifier before deploying the image. -
The Boot Loader Specification has been extended with
/loader/entries.srel file located in the EFI System Partition (ESP)
that disambiguates the format of the entries in the /loader/entries/
directory (in order to discern them from incompatible uses of this
directory by other projects). For entries that follow the
Specification, the string "type1" is stored in this file.bootctl will now write this file automatically when installing the
systemd-boot boot loader. -
kernel-install supports a new initrd_generator= setting in
/etc/kernel/install.conf, that is exported as
$KERNEL_INSTALL_INITRD_GENERATOR to kernel-install plugins. This
allows choosing different initrd generators. -
kernel-install will now create a "staging area" (an initially-empty
directory to gather files for a Boot Loader Specification Type #1
entry). The path to this directory is exported as
$KERNEL_INSTALL_STAGING_AREA to kernel-install plugins, which should
drop files there instead of writing them directly to the final
location. kernel-install will move them when all files have been
prepared successfully. -
New option sort-key= has been added to the Boot Loader Specification
to override the sorting order of the entries in the boot menu. It is
read by sd-boot and bootctl, and will be written by kernel-install,
with the default value of IMAGE_ID= or ID= fields from
os-release. Together, this means that on multiboot installations,
entries should be grouped and sorted in a predictable way. -
The sort order of boot entries has been updated: entries which have
the new field sort-key= are sorted by it first, and all entries
without it are ordered later. After that, entries are sorted by
version so that newest entries are towards the beginning of the list. -
The kernel-install tool gained a new 'inspect' verb which shows the
paths and other settings used. -
sd-boot can now optionally beep when the menu is shown and menu
entries are selected, which can be useful on machines without a
working display. (Controllable via a loader.conf setting.) -
The --make-machine-id-directory= switch to bootctl has been replaced
by --make-entry-directory=, given that the entry directory is not
necessarily named after the machine ID, but after some other suitable
ID as selected via --entry-token= described above. The old name of
the option is still understood to maximize compatibility. -
'bootctl list' gained support for a new --json= switch to output boot
menu entries in JSON format. -
'bootctl is-installed' now supports the --graceful, and various verbs
omit output with the new option --quiet.
Changes in systemd-homed:
-
Starting with v250 systemd-homed uses UID/GID mapping on the mounts
of activated home directories it manages (if the kernel and selected
file systems support it). So far it mapped three UID ranges: the
range from 0β¦60000, the user's own UID, and the range 60514β¦65534,
leaving everything else unmapped (in other words, the 16bit UID range
is mapped almost fully, with the exception of the UID subrange used
for systemd-homed users, with one exception: the user's own UID).
Unmapped UIDs may not be used for file ownership in the home
directory β any chown() attempts with them will fail. With this
release a fourth range is added to these mappings:
524288β¦1879048191. This range is the UID range intended for container
uses, see:https://systemd.io/UIDS-GIDSThis range may be used for container managers that place container OS
trees in the home directory (which is a questionable approach, for
quota, permission, SUID handling and network file system
compatibility reasons, but nonetheless apparently commonplace). Note
that this mapping is mapped 1:1 in a pass-through fashion, i.e. the
UID assignments from the range are not managed or mapped by
systemd-homed, and must be managed with other mechanisms, in the
context of the local system.Typically, a better approach to user namespacing in relevant
container managers would be to leave container OS trees on disk at
UID offset 0, but then map them to a dynamically allocated runtime
UID range via another UID mount map at container invocation
time. That way user namespace UID ranges become strictly a runtime
concept, and do not leak into persistent file systems, persistent
us...
Contributors
Assets 2
v251-rc1
Backwards-incompatible changes:
-
The minimum kernel version required has been bumped from 3.13 to 3.15,
and CLOCK_BOOTTIME is now assumed to always exist. -
C11 with GNU extensions (aka "gnu11") is now used to build our
components. Public API headers are still restricted to ISO C89. -
In v250, a systemd-networkd feature that automatically configures
routes to addresses specified in AllowedIPs= was added and enabled by
default. However, this causes network connectivity issues in many
existing setups. Hence, it has been disabled by default since
systemd-stable 250.3. The feature can still be used by explicitly
configuring RouteTable= setting in .netdev files. -
Jobs started via StartUnitWithFlags() will no longer return 'skipped'
when a Condition*= check does not succeed, restoring the JobRemoved
signal to the behaviour it had before v250. -
The org.freedesktop.portable1 methods GetMetadataWithExtensions() and
GetImageMetadataWithExtensions() have been fixed to provide an extra
return parameter, containing the actual extension release metadata.
The current implementation was judged to be broken and unusable, and
thus the usual procedure of adding a new set of methods was skipped,
and backward compatibility broken instead on the assumption that
nobody can be affected given the current state of this interface. -
All kernels supported by systemd mix RDRAND (or similar) into the
entropy pool at early boot. This means that on those systems, even if
/dev/urandom is not yet initialized, it still returns bytes that that
are at least as high quality as RDRAND. For that reason, we no longer
have reason to invoke RDRAND from systemd itself, which has
historically been a source of bugs. Furthermore, kernels β₯5.6 provide
the getrandom(GRND_INSECURE) interface for returning random bytes
before the entropy pool is initialized without warning into kmsg,
which is what we attempt to use if available. systemd's direct usage
of RDRAND has been removed. x86 systems β₯Broadwell that are running
an older kernel may experience kmsg warnings that were not seen with
250. For newer kernels, non-x86 systems, or older x86 systems, there
should be no visible changes. -
sd-boot will now measure the kernel command line into TPM PCR 12
rather than PCR 8. This improves usefulness of the measurements on
systems where sd-boot is chainloaded from Grub. Grub measures all
commands its executes into PCR 8, which makes it very hard to use
reasonably, hence separate ourselves from that and use PCR 12
instead, which is what certain Ubuntu editions already do. To retain
compatibility with systems running older systemd systems a new meson
option 'efi-tpm-pcr-compat' has been added (which defaults to false).
If enabled, the measurement is done twice: into the new-style PCR 12
and the old-style PCR 8. It's strongly advised to migrate all users
to PCR 12 for this purpose in the long run, as we intend to remove
this compatibility feature in two year's time. -
busctl capture now writes output in the newer pcapng format instead
of pcap. -
An udev rule that imported hwdb matches for USB devices with
lowercase hexadecimal vendor/product ID digits was added in systemd
250. This has been reverted, since uppercase hexadecimal digits are
supposed to be used, and we already had a rule that with the
appropriate match.Users might need to adjust their local hwdb entries.
-
arch_prctl(2) has been moved to the @default set in the syscall filters
(as exposed via the SystemCallFilter= setting in service unit files).
It is apparently used by the linker now.
Changes in the Boot Loader Specification, kernel-install and sd-boot:
-
kernel-install's and bootctl's Boot Loader Specification Type #1
entry generation logic has been reworked. The user may now pick
explicitly by which "token" string to name the installation's boot
entries, via the new /etc/kernel/entry-token file or the new
--entry-token= switch to bootctl. By default β as before β the
entries are named after the local machine ID. However, in "golden
image" environments, where the machine ID shall be initialized on
first boot (as opposed to at installation time before first boot) the
machine ID will not be available at build time. In this case the
--entry-token= switch to bootctl (or the /etc/kernel/entry-token
file) may be used to override the "token" for the entries, for
example the IMAGE_ID= or ID= fields from /etc/os-release. This will
make the OS images independent of any machine ID, and ensure that the
images will not carry any identifiable information before first boot,
but on the other hand means that multiple parallel installations of
the very same image on the same disk cannot be supported.Summary: if you are building golden images that shall acquire
identity information exclusively on first boot, make sure to both
remove /etc/machine-id and to write /etc/kernel/entry-token to the
value of the IMAGE_ID= or ID= field of /etc/os-release or another
suitable identifier before deploying the image. -
The Boot Loader Specification has been extended with
/loader/entries.srel file located in the EFI System Partition (ESP)
that disambiguates the format of the entries in the /loader/entries/
directory (in order to discern them from incompatible uses of this
directory by other projects). For entries that follow the
Specification, the string "type1" is stored in this file.bootctl will now write this file automatically when installing the
systemd-boot boot loader. -
kernel-install supports a new initrd_generator= setting in
/etc/kernel/install.conf, that is exported as
$KERNEL_INSTALL_INITRD_GENERATOR to kernel-install plugins. This
allows choosing different initrd generators. -
kernel-install will now create a "staging area" (an initially-empty
directory to gather files for a Boot Loader Specification Type #1
entry). The path to this directory is exported as
$KERNEL_INSTALL_STAGING_AREA to kernel-install plugins, which should
drop files there instead of writing them directly to the final
location. kernel-install will move them when all files have been
prepared successfully. -
New option sort-key= has been added to the Boot Loader Specification
to override the sorting order of the entries in the boot menu. It is
read by sd-boot and bootctl, and will be written by kernel-install,
with the default value of IMAGE_ID= or ID= fields from
os-release. Together, this means that on multiboot installations,
entries should be grouped and sorted in a predictable way. -
The sort order of boot entries has been updated: entries which have
the new field sort-key= are sorted by it first, and all entries
without it are ordered later. After that, entries are sorted by
version so that newest entries are towards the beginning of the list. -
The kernel-install tool gained a new 'inspect' verb which shows the
paths and other settings used. -
sd-boot can now optionally beep when the menu is shown and menu
entries are selected, which can be useful on machines without a
working display. (Controllable via a loader.conf setting.) -
The --make-machine-id-directory= switch to bootctl has been replaced
by --make-entry-directory=, given that the entry directory is not
necessarily named after the machine ID, but after some other suitable
ID as selected via --entry-token= described above. The old name of
the option is still understood to maximize compatibility. -
'bootctl list' gained support for a new --json= switch to output boot
menu entries in JSON format.
Changes in systemd-homed:
-
Starting with v250 systemd-homed uses UID/GID mapping on the mounts
of activated home directories it manages (if the kernel and selected
file systems support it). So far it mapped three UID ranges: the
range from 0β¦60000, the user's own UID, and the range 60514β¦65534,
leaving everything else unmapped (in other words, the 16bit UID range
is mapped almost fully, with the exception of the UID subrange used
for systemd-homed users, with one exception: the user's own UID).
Unmapped UIDs may not be used for file ownership in the home
directory β any chown() attempts with them will fail. With this
release a fourth range is added to these mappings:
524288β¦1879048191. This range is the UID range intended for container
uses, see https://systemd.io/UIDS-GIDS.This range may be used for container managers that place container OS
trees in the home directory (which is a questionable approach, for
quota, permission, SUID handling and network file system
compatibility reasons, but nonetheless apparently commonplace). Note
that this mapping is mapped 1:1 in a pass-through fashion, i.e. the
UID assignments from the range are not managed or mapped by
systemd-homed, and must be managed with other mechanisms, in the
context of the local system.Typically, a better approach to user namespacing in relevant
container managers would be to leave container OS trees on disk at
UID offset 0, but then map them to a dynamically allocated runtime
UID range via another UID mount map at container invocation
time. That way user namespace UID ranges become strictly a runtime
concept, and do not leak into persistent file systems, persistent
user databases or persistent configuration, thus greatly simplifying
handling, and improving compatibility with home directories intended
to be portable like the ones managed by systemd-homed.
Changes in shared libraries:
- A new libsystemd-core-.so private shared library is
installed under /usr/lib/systemd/system, mirroring the existing
libsystemd-shared-.so library. This allows the ...
Contributors
Assets 2
systemd v250
CHANGES WITH 250:
* Support for encrypted and authenticated credentials has been added.
This extends the credential logic introduced with v247 to support
non-interactive symmetric encryption and authentication, based on a
key that is stored on the /var/ file system or in the TPM2 chip (if
available), or the combination of both (by default if a TPM2 chip
exists the combination is used, otherwise the /var/ key only). The
credentials are automatically decrypted at the moment a service is
started, and are made accessible to the service itself in unencrypted
form. A new tool 'systemd-creds' encrypts credentials for this
purpose, and two new service file settings LoadCredentialEncrypted=
and SetCredentialEncrypted= configure such credentials.
This feature is useful to store sensitive material such as SSL
certificates, passwords and similar securely at rest and only decrypt
them when needed, and in a way that is tied to the local OS
installation or hardware.
* systemd-gpt-auto-generator can now automatically set up discoverable
LUKS2 encrypted swap partitions.
* The GPT Discoverable Partitions Specification has been substantially
extended with support for root and /usr/ partitions for the majority
of architectures systemd supports. This includes platforms that do
not natively support UEFI, because even though GPT is specified under
UEFI umbrella, it is useful on other systems too. Specifically,
systemd-nspawn, systemd-sysext, systemd-gpt-auto-generator and
Portable Services use the concept without requiring UEFI.
* The GPT Discoverable Partitions Specifications has been extended with
a new set of partitions that may carry PKCS#7 signatures for Verity
partitions, encoded in a simple JSON format. This implements a simple
mechanism for building disk images that are fully authenticated and
can be tested against a set of cryptographic certificates. This is
now implemented for the various systemd tools that can operate with
disk images, such as systemd-nspawn, systemd-sysext, systemd-dissect,
Portable services/RootImage=, systemd-tmpfiles, and systemd-sysusers.
The PKCS#7 signatures are passed to the kernel (where they are
checked against certificates from the kernel keyring), or can be
verified against certificates provided in userspace (via a simple
drop-in file mechanism).
* systemd-dissect's inspection logic will now report for which uses a
disk image is intended. Specifically, it will display whether an
image is suitable for booting on UEFI or in a container (using
systemd-nspawn's --image= switch), whether it can be used as portable
service, or attached as system extension.
* The system-extension.d/ drop-in files now support a new field
SYSEXT_SCOPE= that may encode which purpose a system extension image
is for: one of "initrd", "system" or "portable". This is useful to
make images more self-descriptive, and to ensure system extensions
cannot be attached in the wrong contexts.
* The os-release file learnt a new PORTABLE_PREFIXES= field which may
be used in portable service images to indicate which unit prefixes
are supported.
* The GPT image dissection logic in systemd-nspawn/systemd-dissect/β¦
now is able to decode images for non-native architectures as well.
This allows systemd-nspawn to boot images of non-native architectures
if the corresponding user mode emulator is installed and
systemd-binfmtd is running.
* systemd-logind gained new settings HandlePowerKeyLongPress=,
HandleRebootKeyLongPress=, HandleSuspendKeyLongPress= and
HandleHibernateKeyLongPress= which may be used to configure actions
when the relevant keys are pressed for more than 5s. This is useful
on devices that only have hardware for a subset of these keys. By
default, if the reboot key is pressed long the poweroff operation is
now triggered, and when the suspend key is pressed long the hibernate
operation is triggered. Long pressing the other two keys currently
does not trigger any operation by default.
* When showing unit status updates on the console during boot and
shutdown, and a service is slow to start so that the cylon animation
is shown, the most recent sd_notify() STATUS= text is now shown as
well. Services may use this to make the boot/shutdown output easier
to understand, and to indicate what precisely a service that is slow
to start or stop is waiting for. In particular, the per-user service
manager instance now reports what it is doing and which service it is
waiting for this way to the system service manager.
* The service manager will now re-execute on reception of the
SIGRTMIN+25 signal. It previously already did that on SIGTERM β but
only when running as PID 1. There was no signal to request this when
running as per-user service manager, i.e. as any other PID than 1.
SIGRTMIN+25 works for both system and user managers.
* The hardware watchdog logic in PID 1 gained support for operating
with the default timeout configured in the hardware, instead of
insisting on re-configuring it. Set RuntimeWatchdogSec=default to
request this behavior.
* A new kernel command line option systemd.watchdog_sec= is now
understood which may be used to override the hardware watchdog
time-out for the boot.
* A new setting DefaultOOMScoreAdjust= is now supported in
/etc/systemd/system.conf + /etc/systemd/user.conf that may be used to
set the default process OOM score adjustment value for processes
forked off the service manager. For per-user service managers this
now defaults to 100, but for per-system service managers is left as
is. This means that by default now services forked off the user
service manager are more likely to be killed by the OOM killer than
system services or the managers themselves.
* A new per-service setting RestrictFileSystems= as been added that
restricts the file systems a service has access to by their type.
This is based on the new BPF LSM of the Linux kernel. It provides an
effective way to make certain API file systems unavailable to
services (and thus minimizing attack surface). A new command
"systemd-analyze filesystems" has been added that lists all known
file system types (and how they are grouped together under useful
group handles).
* Services now support a new setting RestrictNetworkInterfaces= for
restricting access to specific network interfaces.
* Service unit files gained new settings StartupAllowedCPUs= and
StartupAllowedMemoryNodes=. These are similar to their counterparts
without the "Startup" prefix and apply during the boot process
only. This is useful to improve boot-time behavior of the system and
assign resources differently during boot than during regular
runtime. This is similar to the preexisting StartupCPUWeight=
vs. CPUWeight.
* Related to this: the various StartupXYZ= settings
(i.e. StartupCPUWeight=, StartupAllowedCPUs=, β¦) are now also applied
during shutdown. The settings not prefixed with "Startup" hence apply
during regular runtime, and those that are prefixed like that apply
during boot and shutdown.
* A new per-unit set of conditions/asserts
[Condition|Assert][Memory|CPU|IO]Pressure= have been added to make a
unit skip/fail activation if the system's (or a slice's) memory/cpu/io
pressure is above the configured threshold, using the kernel PSI
feature. For more details see systemd.unit(5) and
https://www.kernel.org/doc/html/latest/accounting/psi.html
* The combination of ProcSubset=pid and ProtectKernelTunables=yes and/or
ProtectKernelLogs=yes can now be used.
* The default maximum numbers of inodes have been raised from 64k to 1M
for /dev, and from 400k to 1M for /tmp.
* The per-user service manager learnt support for communicating with
systemd-oomd to acquire OOM kill information.
* A new service setting ExecSearchPath= has been added that allows
changing the search path for executables for services. It affects
where we look for the binaries specified in ExecStart= and similar,
and the specified directories are also added the $PATH environment
variable passed to invoked processes.
* A new setting RuntimeRandomizedExtraSec= has been added for service
and scope units that allows extending the runtime time-out as
configured by RuntimeMaxSec= with a randomized amount.
* The syntax of the service unit settings RuntimeDirectory=,
StateDirectory=, CacheDirectory=, LogsDirectory= has been extended:
if the specified value is now suffixed with a colon, followed by
another filename, the latter will be created as symbolic link to the
specified directory. This allows creating these service directories
t...
v250-rc3
v250-rc2
v250-rc1
systemd v249
CHANGES WITH 249:
* When operating on disk images via the --image= switch of various
tools (such as systemd-nspawn or systemd-dissect), or when udev finds
no 'root=' parameter on the kernel command line, and multiple
suitable root or /usr/ partitions exist in the image, then a simple
comparison inspired by strverscmp() is done on the GPT partition
label, and the newest partition is picked. This permits a simple and
generic whole-file-system A/B update logic where new operating system
versions are dropped into partitions whose label is then updated with
a matching version identifier.
* systemd-sysusers now supports querying the passwords to set for the
users it creates via the "credentials" logic introduced in v247: the
passwd.hashed-password.<user> and passwd.plaintext-password.<user>
credentials are consulted for the password to use (either in UNIX
hashed form, or literally). By default these credentials are inherited
down from PID1 (which in turn imports it from a container manager if
there is one). This permits easy configuration of user passwords
during first boot. Example:
# systemd-nspawn -i foo.raw --volatile=yes --set-credential=passwd.plaintext-password.root:foo
Note that systemd-sysusers operates in purely additive mode: it
executes no operation if the declared users already exist, and hence
doesn't set any passwords as effect of the command line above if the
specified root user exists already in the image. (Note that
--volatile=yes ensures it doesn't, though.)
* systemd-firstboot now also supports querying various system
parameters via the credential subsystems. Thus, as above this may be
used to initialize important system parameters on first boot of
previously unprovisioned images (i.e. images with a mostly empty
/etc/).
* PID 1 may now show both the unit name and the unit description
strings in its status output during boot. This may be configured with
StatusUnitFormat=combined in system.conf or
systemd.status-unit-format=combined on the kernel command line.
* The systemd-machine-id-setup tool now supports a --image= switch for
provisioning a machine ID file into an OS disk image, similar to how
--root= operates on an OS file tree. This matches the existing switch
of the same name for systemd-tmpfiles, systemd-firstboot, and
systemd-sysusers tools.
* Similarly, systemd-repart gained support for the --image= switch too.
In combination with the existing --size= option, this makes the tool
particularly useful for easily growing disk images in a single
invocation, following the declarative rules included in the image
itself.
* systemd-repart's partition configuration files gained support for a
new switch MakeDirectories= which may be used to create arbitrary
directories inside file systems that are created, before registering
them in the partition table. This is useful in particular for root
partitions to create mount point directories for other partitions
included in the image. For example, a disk image that contains a
root, /home/, and /var/ partitions, may set MakeDirectories=yes to
create /home/ and /var/ as empty directories in the root file system
on its creation, so that the resulting image can be mounted
immediately, even in read-only mode.
* systemd-repart's CopyBlocks= setting gained support for the special
value "auto". If used, a suitable matching partition on the booted OS
is found as source to copy blocks from. This is useful when
implementing replicating installers, that are booted from one medium
and then stream their own root partition onto the target medium.
* systemd-repart's partition configuration files gained support for a
Flags=, a ReadOnly= and a NoAuto= setting, allowing control of these
GPT partition flags for the created partitions: this is useful for
marking newly created partitions as read-only, or as not being
subject for automatic mounting from creation on.
* The /etc/os-release file has been extended with two new (optional)
variables IMAGE_VERSION= and IMAGE_ID=, carrying identity and version
information for OS images that are updated comprehensively and
atomically as one image. Two new specifiers %M, %A now resolve to
these two fields in the various configuration options that resolve
specifiers.
* portablectl gained a new switch --extension= for enabling portable
service images with extensions that follow the extension image
concept introduced with v248, and thus allows layering multiple
images when setting up the root filesystem of the service.
* systemd-coredump will now extract ELF build-id information from
processes dumping core and include it in the coredump report.
Moreover, it will look for ELF .note.package sections with
distribution packaging meta-information about the crashing process.
This is useful to directly embed the rpm or deb (or any other)
package name and version in ELF files, making it easy to match
coredump reports with the specific package for which the software was
compiled. This is particularly useful on environments with ELF files
from multiple vendors, different distributions and versions, as is
common today in our containerized and sand-boxed world. For further
information, see:
https://systemd.io/COREDUMP_PACKAGE_METADATA
* A new udev hardware database has been added for FireWire devices
(IEEE 1394).
* The "net_id" built-in of udev has been updated with three
backwards-incompatible changes:
- PCI hotplug slot names on s390 systems are now parsed as
hexadecimal numbers. They were incorrectly parsed as decimal
previously, or ignored if the name was not a valid decimal
number.
- PCI onboard indices up to 65535 are allowed. Previously, numbers
above 16383 were rejected. This primarily impacts s390 systems,
where values up to 65535 are used.
- Invalid characters in interface names are replaced with "_".
The new version of the net naming scheme is "v249". The previous
scheme can be selected via the "net.naming-scheme=v247" kernel
command line parameter.
* sd-bus' sd_bus_is_ready() and sd_bus_is_open() calls now accept a
NULL bus object, for which they will return false. Or in other words,
an unallocated bus connection is neither ready nor open.
* The sd-device API acquired a new API function
sd_device_get_usec_initialized() that returns the monotonic time when
the udev device first appeared in the database.
* sd-device gained a new APIs sd_device_trigger_with_uuid() and
sd_device_get_trigger_uuid(). The former is similar to
sd_device_trigger() but returns a randomly generated UUID that is
associated with the synthetic uevent generated by the call. This UUID
may be read from the sd_device object a monitor eventually receives,
via the sd_device_get_trigger_uuid(). This interface requires kernel
4.13 or above to work, and allows tracking a synthetic uevent through
the entire device management stack. The "udevadm trigger --settle"
logic has been updated to make use of this concept if available to
wait precisely for the uevents it generates. "udevadm trigger" also
gained a new parameter --uuid that prints the UUID for each generated
uevent.
* sd-device also gained new APIs sd_device_new_from_ifname() and
sd_device_new_from_ifindex() for allocating an sd-device object for
the specified network interface. The former accepts an interface name
(either a primary or an alternative name), the latter an interface
index.
* The native Journal protocol has been documented. Clients may talk
this as alternative to the classic BSD syslog protocol for locally
delivering log records to the Journal. The protocol has been stable
for a long time and in fact been implemented already in a variety
of alternative client libraries. This documentation makes the support
for that official:
https://systemd.io/JOURNAL_NATIVE_PROTOCOL
* A new BPFProgram= setting has been added to service files. It may be
set to a path to a loaded kernel BPF program, i.e. a path to a bpffs
file, or a bind mount or symlink to one. This may be used to upload
and manage BPF programs externally and then hook arbitrary systemd
services into them.
* The "home.arpa" domain that has been officially declared as the
choice for domain for local home networks per RFC 8375 has been added
to the default NTA list of resolved, since DNSSEC is generally not
available on private domains.
* The CPUAffinity= setting of unit files now resolves "%" specifiers.
* A new ManageForeignRoutingPolicyRules= setting has been added to
.network files which may be used to exclud...
v249-rc3
poettering
Lennart Poettering
systemd v249-rc3