v246 is long released. Hence the new scheme should be named v247.
(Interesting, how we pretty systematically for the last releases changed
the scheme only every second release)
The phrase "routing domains" is used to mean both route-only domains and search
domains. Route-only domains are always called like that, and not just "route domains".
Some paragraphs are reordered to describe synthetisized records first, then
LLMNR, then various ways quries are routed.
Fixes#8928, hopefully.
For encrypted block devices that we need to unlock from the initramfs,
we currently rely on dracut shipping `cryptsetup.target`. This works,
but doesn't cover the case where the encrypted block device requires
networking (i.e. the `remote-cryptsetup.target` version). That target
however is traditionally dynamically enabled.
Instead, let's rework things here by adding a `initrd-cryptsetup.target`
specifically for initramfs encrypted block device setup. This plays the
role of both `cryptsetup.target` and `remote-cryptsetup.target` in the
initramfs.
Then, adapt `systemd-cryptsetup-generator` to hook all generated
services to this new unit when running from the initrd. This is
analogous to `systemd-fstab-generator` hooking all mounts to
`initrd-fs.target`, regardless of whether they're network-backed or not.
Using `bootctl set-default @current` will set the default loader entry
to the currently booted entry as read from the `LoaderEntrySelected` EFI
variable.
Also `bootctl set-oneshot @current` will set the oneshot loader entry to
the current booted entry.
Correspondingly `@default` and `@oneshot` can be used to read from the
LoaderEntryDefault and LoaderEntryOneshot EFI variables.
Add a new target for synchronizing units that wish to run once during
the first boot of the system. The machine-id will be committed to disk
only after the target has been reached, thus ensuring that all units
ordered before it had a chance to complete.
No functional change is intended.
The general pattern of changes:
-usb:v04F3p2B7C*
+usb:v04F3p2B7C:*
This is mostly a clarification, to make the part that makes the usb vXXXXpYYYY
part visually separated. It would only make a difference if we added further
keys with a different number of digits, which is unlikely.
-usb:v0627p0001:*QEMU USB Keyboard*
-usb:v0627p0001:*QEMU USB Mouse*
-usb:v0627p0001:*QEMU USB Tablet*
+usb:v0627p0001:*QEMU USB Keyboard*:*
+usb:v0627p0001:*QEMU USB Mouse*:*
+usb:v0627p0001:*QEMU USB Tablet*:*
Again, only a clarification. We know that ":" will appear somewhere later in
the match key, so anything that matches "…Keyboard*" will also match "…Keyboard*:*".
-evdev:name:ETPS/2 Elantech Touchpad:dmi:*svnASUSTeKComputerInc.:pnN53SV*
+evdev:name:ETPS/2 Elantech Touchpad:dmi:*svnASUSTeKComputerInc.:pnN53SV:*
This makes the match narrower. Previously we would match product "N53SV"
and "N53SV2", "N53SV3", and others. Here we are saying that the ':pn' part must
match exactly. Most of the changes in this patch match this pattern. I made a few
judgement calls and used "pn…*:*" when I wasn't sure if the full pn is included:
-evdev:name:Dell WMI hotkeys:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*
+evdev:name:Dell WMI hotkeys:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*:*
-evdev:name:Cypress APA Trackpad ?cyapa?:dmi:*:svnHewlett-Packard*:pnFalco*:
+evdev:name:Cypress APA Trackpad ?cyapa?:dmi:*:svnHewlett-Packard*:pnFalco*:*
This more like the "QEMU" example above, since all dmi strings end in ":", so
anything which matches the old version will also match the new version.
-evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:*
I replaced trailing ":pvr*" by ":*". This makes no functional difference because
we expect "pvr" to always appear in the dmi string. This makes patterns shorter.
-evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:*
OTOH, ":pn*" is kept. This is because almost patterns include ":pn*", and if we
skip it, we should make it clear that this is on purpose, that we really want to
match any product name.
The python script to generate autosuspend rules is updated to use ":*" too.
Inspired by https://github.com/systemd/systemd/pull/17281#discussion_r501489750.
bootctl implements three types of operation: those that work with an EFI
boot loader, those which work with any EFI boot loader that implements
the boot loader spec + interface, and finally those specific to sd-boot.
Previously the --help text and the man page mixed them all up. Let's put
them clearly in three separate sections however, to communicate clearly
what is supposed to work everywhere, and what is specific to
systemd-boot or boot loaders implementing the two specs.
This adjusts wording here and there, but is mostly just about
re-ordering existing docs, and putting them under new sections.
We would return ENOENT, which is extremely confusing. Strace is not helpful because
no *file* is actually missing. So let's add some logs at debug level and also use
a custom return code. Let all user-facing utilities print a custom error message
in that case.
The variable is renamed to SYSTEMD_PAGERSECURE (because it's not just about
less now), and we automatically enable secure mode in certain cases, but not
otherwise.
This approach is more nuanced, but should provide a better experience for
users:
- Previusly we would set LESSSECURE=1 and trust the pager to make use of
it. But this has an effect only on less. We need to not start pagers which
are insecure when in secure mode. In particular more is like that and is a
very popular pager.
- We don't enable secure mode always, which means that those other pagers can
reasonably used.
- We do the right thing by default, but the user has ultimate control by
setting SYSTEMD_PAGERSECURE.
Fixes#5666.
v2:
- also check $PKEXEC_UID
v3:
- use 'sd_pid_get_owner_uid() != geteuid()' as the condition
Also, document this functionality more prominently, including with a
reference from sd_event_exit().
This is mostly to make things complete, as previously we supported NULL
callbacks only in _add_time() and _add_signal(). However, I think this
makes snese for IO event sources too (think: when some fd such as a pipe
end sees SIGHUP or so, exit), as well as defer or post event sources (i.e. exit
once we got nothing else to do). This also adds support for inotify
event sources, simply to complete things (I can't see the immediate use,
but maybe someone else comes up with it).
The only event source type that doesn't allow callback=NULL now are exit
callbacks, but for them they make little sense, as the event loop is
exiting then anyway.
Some extra safety when invoked via "sudo". With this we address a
genuine design flaw of sudo, and we shouldn't need to deal with this.
But it's still a good idea to disable this surface given how exotic it
is.
Prompted by #5666
Currently systemd-detect-virt fails to detect running under PowerVM.
Add code to detect PowerVM based on code in util-linux.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
We have three somewhat separate ideas: what the directory is for, what $TMPDIR is for, and security considerations.
Let's use paragraphs.
Also, conjunctions in titles aren't capitalized usually.
Let's explicitly deactivate all home dirs on shutdown, in order to
properly synchronizing unmounting and avoiding blocking devices.
Previously, we'd rely on automatic deactivation when home directories
become unused. However, that scheme is asynchronous, and ongoing
deactviations might conflicts with attempts to unmount /home. Let's fix
that by providing an explicit service systemd-homed-activate.service
whose only job is to have a ExecStop= line that explicitly deactivates
all home directories on shutdown. This service can the be ordered after
home.mount and similar, ensuring that we'll first deactivate all homes
before deactivating /home itself during shutdown.
This is kept separate from systemd-homed.service so that it is possible
to restart systemd-homed.service without deactivating all home
directories.
Fixes: #16842
We should avoid duplicating lengthy description of very similar concepts.
--root-hash-sig follows the same semantics as RootHashSig=, so just refer
the reader to the other man page. --root-hash doesn't implement the same
features as RootHash=, so we can't fully replace the description, but let's
give the user a hint to look at the other man page too.
For #17177.
Also, reword the description a bit. "As a string" is meaningless in the context
of commandline arguments, where evyrything is a string. This is not a
strongly-typed programming language where 5 is a number but "5" is something
completely different. Here both 5 and "5" are indistinguishable. The original
text was trying to say that a location name should be given and not a number,
so say "time zone location name".
For #17177.
In table titles, capitalize only the first word (they are rather long and
it is easier to read when it looks like a normal sentence).
Adjust some phrases to make them clearer when reported as unclear in #17177.
It can be one of "foreign", "missing", "stub", "static", "uplink",
depending on how /etc/resolv.conf is set up:
foreign → someone/something else manages /etc/resolv.conf,
systemd-resolved is just the consumer
missing → /etc/resolv.conf is missing altogether
stub/static/uplink → the file is managed by resolved, with the
well-known modes
Fixes: #17159
It always was the intention to expose this as trusted field _TID=, i.e.
automatically determine it from journald via some SCM_xyz field or so,
but this is never happened, and it's unlikely this will be added anytime
soon to the kernel either, hence let's just generate this sender side,
even if it means it's untrusted.
Adds support for LUKS detached header device on kernel
command line. It's introduced via extension to existing
luks.options 'header=' argument beyond colon (see examples
below). If LUKS header device is specified it's expected
to contain filesystem with LUKS header image on a path
specified in the first part of header specification.
The second parameter 'luks.data' specifies LUKS data device
supposed to be paired with detached LUKS header (note that
encrypted LUKS data device with detached header is unrecognisable
by standard blkid probe).
This adds support for LUKS encrypted rootfs partition with
detached header. It can also be used for initializing online LUKS2
encryption of data device.
Examples:
luks.data=<luks_uuid>=/dev/sdz
luks.data=<luks_uuid>=/dev/vg/lv
luks.data=<luks_uuid>=/dev/mapper/lv
luks.data=<luks_uuid>=PARTUUID=<part_uuid>
luks.data=<luks_uuid>=PARTLABEL=<part_uuid>
luks.options=<luks_uuid>=header=/header/path:UUID=<fs_uuid>
luks.options=<luks_uuid>=header=/header/path:PARTUUID=<part_uuid>
luks.options=<luks_uuid>=header=/header/path:PARTLABEL=<part_label>
luks.options=<luks_uuid>=header=/header/path:LABEL=<fs_label>
luks.options=<luks_uuid>=header=/header/path:/dev/sdx
luks.options=<luks_uuid>=header=/header/path:/dev/vg/lv
The '/header/path' is considered to be relative location within
filesystem residing on the header device specified beyond colon
character
