Same idea as with bootctl, we might be doing image builds from a
system that doesn't boot with UEFI but we still might want to measure
stuff for the image we're building so let's not gate this behind
ENABLE_BOOTLOADER.
bootctl is rather useful to have, even if on a system without UEFI,
as it has a number of verbs that are unrelated to UEFI (e.g kernel-identify),
and more importantly, it supports --root to operate on directory trees
(which could be intended to be deployed on UEFI) so let's make sure we
always build it.
If user requests hybrid sleep, we should always use 'suspend'
disk mode. If that's not supported, let's correctly report it
so they can choose plain hibernation instead. HybridSleepMode=
serves no purpose in this case and should be removed.
Addresses https://github.com/systemd/systemd/pull/29681#discussion_r1369812785
This is like --cat-config, but omits the comments and empty lines.
The name is incoungrous with --cat-config, but I don't see a nice way to
call it that wouldn't be annoyingly long.
pager_open() is moved to cat_config() to remove some lines from run().
When looking at configuration, often a user wants to suppress the comments and
just look at the parts that actually configure something, roughly equivalent to
systemd-analyze cat-config … | rg -v '^(#|;|$)
This switch implements this natively, skipping lines that start with a comment
character or only contain whitespace.
For formats that have section headers, section headers are skipped, if only
followed by stuff that would be skipped. (The last section header is printed
when we're about to print some actual output.)
Note that the caller doesn't know if the format has headers or not. We do format
type detection in pretty-print.c. So the caller only specifies tldr=true|false, and
conf_files_cat() figures out if the format has headers and whether those should
be handled specially.
The comments that show the file name are always printed, even if all of the file
is suppressed.
This is a partial answer to the discussions in
https://github.com/systemd/systemd/pull/28919,
https://github.com/systemd/systemd/pull/29248. If the default config is shown in
config files, the user can conveniently use '--tldr' to show the relevant parts.
SuspendState= not to include "disk"
I don't know why these existed in the first place, but as I
justified in the comments, it's simply not sensible to allow
HibernateState= or HybridSleepState= to take values other than
'disk'. So let's just remove those options. Also, SuspendState=
should not contain 'disk'.
If `foo+3-0.efi` is booted when there are some files in `foo.efi.extra.d`,
those files are ignored. But after the boot is blessed and the system rebooted,
those file are taken into account, and the boot is different from first
boot. This behavior is a bit puzzling.
Instead we now ignore the counter and always look for the extra files in
`foo.efi.extra.d` and always boot the same way.
Automatically softreboot if the nextroot has been set up with an OS
tree, or automatically kexec if a kernel has been loaded with kexec
--load.
Add SYSTEMCTL_SKIP_AUTO_KEXEC and SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT to
skip the automated switchover.
Currently we have a 100ms delay which allows for people to enter/show
the boot menu even when timeout is set to zero.
In a handful of cases, that may not be needed - both in terms of access
policy, as well as latency.
For example: the option to provide the boot menu may be hidden behind an
"expert only" UX in the OS, to avoid end users from accidentally
entering it.
In addition, the current 100ms input polling may cause unexpected
additional delays in the boot. Some example numbers from my SteamDeck:
- boot counting/rename/flush doubles 300us -> 600us
- seed/hash setup doubles 900us -> 1800us
- kernel/image load gets ~40% slower 107ms -> 167ms
It's not entirely clear why the UEFI calls gets slower, nevertheless the
information in itself proves useful.
This commit introduces a new option "menu-disabled", which omits the
100ms delay. The option is documented throughout the manual pages as
well as the Boot Loader Specification.
v2:
- use STR_IN_SET
v3:
- drop erroneous whitespace
v4:
- add a new LoaderFeature bit,
- don't change ABI keep TIMEOUT_* tokens the same
- move new token in the 64bit range, update API and storage for it
- change inc/dec behaviour to TIMEOUT_MIN : TIMEOUT_MENU_FORCE
- user cannot opt-in from sd-boot itself, add assert_not_reached()
v5:
- s/Menu disablement control/Menu can be disabled/
- rewrap comments to 109
- use SYNTHETIC_ERRNO(EOPNOTSUPP)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
With file systems that have volume management functionalities or
volume managers like LVM, it's fine for the backing device of a mount
to disappear after mounted. Currently, we enforce BindsTo= or
StopPropagatedFrom= on the backing device, thus prohibiting such
cases. Instead, let's make this configurable through x-systemd.device-bound.
Closes#16801Closes#29543
https://github.com/systemd/systemd/pull/29582 adds the "v254" name. This also
changes what the default is and what "latest" refers to. Without the name, the
code could be enabled via runtime configuration. Nevertheless, it could be
enabled at compilation time. In other words:
meson setup build -Ddefault-net-naming-scheme=v254
would work, but
net.naming-scheme=v254
would fail.
It is possible that people were using the compile-time override, so I think
we should allow "v254" scheme to stay and clearly document that it wasn't the
default.
Unfortunately, unless people manually introduced the compile-time override, we
were never actually testing the new code too. So all the pull request testing
was not useful.
Let's support the same filtering options that we also support in
udevadm trigger in udevadm info to filter the devices produced by
--export-db.
One difference is that all properties specified by --propery-match=
have to be satisfied in udevadm info unlike udevadm trigger where just
one of them has to be satisfied.
Instead of mounting over, do an atomic swap using mount beneath, if
available. This way assets can be mounted again and again (e.g.:
updates) without leaking mounts.
Each filename should be a separate <term>, so that they separated in the
formatted text. Also, we list files in documentation in priority order, but
here they were in reverse order. Also, rework the description of
$KERNEL_INSTALL_CONF_ROOT to say that it makes kernel-install not look at the
other files. This requires some more words, so make this a separate paragraph
and refer from individual items to it. Also, drop some sentences with "Read by
...", they were already outdated.
Partial fix for #28771.
Co-authored-by: Emil Renner Berthing <systemd@esmil.dk>
Before this commit, $USER, $HOME, $LOGNAME and $SHELL are only
set when User= is set for the unit. For system service, this
results in different behaviors depending on whether User=root is set.
$USER always makes sense on its own, so let's set it unconditionally.
Ideally $HOME should be set too, but it causes trouble when e.g. getty
passes '-p' to login(1), which then doesn't override $HOME. $LOGNAME and
$SHELL are more like "login environments", and are generally not
suitable for system services. Therefore, a new option SetLoginEnvironment=
is also added to control the latter three variables.
Fixes#23438
Replaces #8227
This changes the doc-sync meson target from a simple rsync command to a
script that:
* puts the documentation in a subdirectory according to the version
* injects a bit of javascript to add a drop-down to switch between versions
* updates an index.json file with the newly uploaded version
* keeps the latest/ directory up to date with the latest version
* supports a --no-latest switch to be used when uploading older versions
Currently only an auto-reboot-to-firmware entry is available. For other
features - like reboot and power off - one needs to press the uppercase
B and O respectively.
Embedded devices may be missing a full fledged keyboard, so allow for
sd-boot to generate those entries.
v2:
- add to the config parser/man/bootctl/sd-boot info screen
- keep them off by default
- add the (O)ff and re(B)oot help text if boot entries are not shown
- drop irrelevant get_os_indications_supported() comment
- s/ShutDown/Shutdown/
v3:
- cast shutdown_system() reboot_system() to void
v4:
- shutdown -> poweroff
- add trailing ",ignoring" in parser message
- drop explicit default state assignment to "false"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This adds --make-ddi=confext, --make-ddi=sysext, --make-ddi=portable, to
make it really easiy to generate DDIs of the specified class. It
it's ultimately just a fancy wrapper around some defaults and in
particular --definitions=.
This makes it very easy to generate a confext:
$ systemd-repart -C --private-key=privkey.pem --certificate=cert.crt -s mytree/ mytree.confext.raw
This specifies a directory to which CopyFiles= is considered relative.
If unset defaults to the --root=/--image= setting, or host / otherwise.
This is very similar to --root= but is much more focussed: it is really
and exclusively about CopyFiles= (and related settings such as
ExcludeFiles=) and does not affect any of the settings, i.e. it doesn't
affect CopyBlocks=, the machine ID/seed handling, or where definitions
are read from.
In fact, --root= and --copy-source= may be combined for example to
use the machine ID and similar from one tree, but the copy the files
from another.
The option was introduced with systemd v250 although it went
undocumented. It effectively sits between Default and OneShot, in term
of priority.
It is repeatedly updated as long as loader.conf default is "@saved" and
the OneShot is not set.
v2:
- squash some typos
v3:
- special mention to default @saved + loader.conf reference
- reword update side, to avoid misleading that it's needlessly
overwritten
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The variable was introduced with systemd v250 although it went
completely undocumented, even though sd-boot will honour and print it
separately (from the loader.conf one) in the boot help screen.
Document it in the systemd-boot and hint about it in loader.conf manual
pages.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This adds a new script tools/check-version-history.py and a corresponding
test when building in developer mode. It checks manpages (except dbus
documentation which is handled by update-dbus-docs) for missing version
history information.
It also adds ignore lists based on version 183 (the version that our version
annotations go back to). These can be augmented if we want to ignore other
elements if it doesn't make sense for them to have version annotations.
This adds an explicit service for initializing the TPM2 SRK. This is
implicitly also done by systemd-cryptsetup, hence strictly speaking
redundant, but doing this early has the benefit that we can parallelize
this in a nicer way. This also write a copy of the SRK public key in PEM
format to /run/ + /var/lib/, thus pinning the disk image to the TPM.
Making the SRK public key is also useful for allowing easy offline
encryption for a specific TPM.
Sooner or later we should probably grow what this service does, the
above is just the first step. For example, the service should probably
offer the ability to reset the TPM (clear the owner hierarchy?) on a
factory reset, if such a policy is needed. And we might want to install
some default AK (?).
Fixes: #27986
Also see: #22637
I have no idea what went on in my mind when I used a path in /var/ for
the tpm2 event log we now keep for userspace measurements. The
measurements are only valid for the current boot, hence should not be
persisted (in particular as they cannot be rotated, hence should not
grow without bounds).
Fix that, simply move from /var/log/ to /run/log/.
Add a new boolean for units, SurviveFinalKillSignal=yes/no. Units that
set it will not have their process receive the final sigterm/sigkill in
the shutdown phase.
This is implemented by checking if a process is part of a cgroup marked
with a user.survive_final_kill_signal xattr (or a trusted xattr if we
can't set a user one, which were added only in kernel v5.7 and are not
supported in CentOS 8).
'systemctl status /../dev' now looks for 'dev.mount', not '-..-dev.service',
and 'systemctl status /../foo' looks for 'foo.mount', not '-..-foo.service'. I
think this much more useful. I think the escaping is not very useful, so I plan
to submit a later series which changes that behaviour. But I think this first
step here is already useful on its own.
Note that the patch is smaller than it seems: before, is_device_path() would
return true only for absolute paths, so moving of is_device_path() under the
path_is_absolute() conditional doesn't influence the logic.
For us, this is a compatibility mode, but most likely it is there to stay: the
kernel Makefile's install target expects to be able to call /bin/installkernel.
We want people who build their own kernels to use this, so that they use
kernel-install and get support for all the functionality provided by it,
including building of UKIs and other new features. So let's actually advertise
that this exists and works.
The benefit of using this setting is that user and group IDs, especially dynamic and random
IDs used by DynamicUser=, can be used in firewall configuration easily.
Example:
```
[Service]
NFTSet=user:inet:filter:serviceuser
```
Corresponding NFT rules:
```
table inet filter {
set serviceuser {
typeof meta skuid
}
chain service_output {
meta skuid @serviceuser accept
drop
}
}
```
```
$ cat /etc/systemd/system/dunft.service
[Service]
DynamicUser=yes
NFTSet=user:inet:filter:serviceuser
ExecStart=/bin/sleep 1000
[Install]
WantedBy=multi-user.target
$ sudo nft list set inet filter serviceuser
table inet filter {
set serviceuser {
typeof meta skuid
elements = { 64864 }
}
}
$ ps -n --format user,group,pid,command -p `systemctl show dunft.service -P MainPID`
USER GROUP PID COMMAND
64864 64864 55158 /bin/sleep 1000
```
New directive `NFTSet=` provides a method for integrating dynamic cgroup IDs
into firewall rules with NFT sets. The benefit of using this setting is to be
able to use control group as a selector in firewall rules easily and this in
turn allows more fine grained filtering. Also, NFT rules for cgroup matching
use numeric cgroup IDs, which change every time a service is restarted, making
them hard to use in systemd environment.
This option expects a whitespace separated list of NFT set definitions. Each
definition consists of a colon-separated tuple of source type (only "cgroup"),
NFT address family (one of "arp", "bridge", "inet", "ip", "ip6", or "netdev"),
table name and set name. The names of tables and sets must conform to lexical
restrictions of NFT table names. The type of the element used in the NFT filter
must be "cgroupsv2". When a control group for a unit is realized, the cgroup ID
will be appended to the NFT sets and it will be be removed when the control
group is removed. systemd only inserts elements to (or removes from) the sets,
so the related NFT rules, tables and sets must be prepared elsewhere in
advance. Failures to manage the sets will be ignored.
If the firewall rules are reinstalled so that the contents of NFT sets are
destroyed, command systemctl daemon-reload can be used to refill the sets.
Example:
```
table inet filter {
...
set timesyncd {
type cgroupsv2
}
chain ntp_output {
socket cgroupv2 != @timesyncd counter drop
accept
}
...
}
```
/etc/systemd/system/systemd-timesyncd.service.d/override.conf
```
[Service]
NFTSet=cgroup:inet:filter:timesyncd
```
```
$ sudo nft list set inet filter timesyncd
table inet filter {
set timesyncd {
type cgroupsv2
elements = { "system.slice/systemd-timesyncd.service" }
}
}
```
This was requested, though I think an issue was never filed. If people are
supposed to invoke it, even for testing, then it's reasonable to make it
"public".
I was missing an example of how to use cryptenroll. We have that, but in
another page. Instead of repeating, let's just direct the user to the right
place.
Also, reformat synopsis to the "official" non-nested syntax.
The tool initially just measured the boot phase, but was subsequently
extended to measure file system and machine IDs, too. At AllSystemsGo
there were request to add more, and make the tool generically
accessible.
Hence, let's rename the binary (but not the pcrphase services), to make
clear the tool is not just measureing the boot phase, but a lot of other
things too.
The tool is located in /usr/lib/ and still relatively new, hence let's
just rename the binary and be done with it, while keeping the unit names
stable.
While we are at it, also move the tool out of src/boot/ and into its own
src/pcrextend/ dir, since it's not really doing boot related stuff
anymore.
I recently tried adding a FIDO2-Device as an unlocking method to the LUKS2 partition containing my Fedora install.
When trying to do this, I stumbled upon the here edited man files detailing how to do this.
I however could not unlock my partition with my FIDO2-Device after editing /etc/crypttab and rebooting.
As I found out after a while, I needed to regenerate / update my currently running / used initramfs (https://unix.stackexchange.com/a/705809).
This would have most likely solved itself for me with the next kernel update install (as far as I understand).
So I propose changing the files edited here to recommend or at least inform the user about this.
Let's replace the "compat" module in our proposed nsswitch.conf
configuration with "files", since it is not 1995 anymore.
Fedora and other distros have deprecated and removed NIS support a while
back. While others still retain some support I am not sure we should
advertise it in our examples. Downstream can of course still use
"compat" instead of "files" if they want to, but let's not confuse
people who don't care about NIS anymore with this.
Also, bring the nsswitch.conf snippet in README in line with what our
man pages say.
Also see: https://fedoraproject.org/wiki/Changes/retire_NIS_user_space_utils
As I noticed a lot of missing information when trying to implement checking
for missing info. I reimplemented the version information script to be more
robust, and here is the result.
Follow up to ec07c3c80b
This adds a new "PollLimit" pair of settings to .socket units, very
similar to existing "TriggerLimit" logic. The differences are:
* PollLimit focusses on the polling on the sockets, and pauses that
temporarily if a ratelimit on that is reached. TriggerLimit otoh
focusses on the triggering effect of socket units, and stops
triggering once the ratelimit is hit.
* While the trigger limit being hit is an action that causes the socket
unit to fail the polling limit being reached will just temporarily
disable polling on the socket fd, and it is resumed once the ratelimit
interval is over.
* When a socket unit operates on multiple socket fds (e,g, ListenStream=
on both some ipv6 and an ipv4 address or so). Then the PollLimit will
be specific to each fd, while the trigger limit is specific to the
whole unit.
Implementation-wise this is mostly a wrapper around sd-event's
sd_event_source_set_ratelimit(), which exposes the desired behaviour
directly.
Usecase for all of this: socket services which when overloaded with
connections should just slow down reception of it, but not fail
persistently.
As pointed out in the review, all this applies to the user services too, so are
not managed by the "init system", but by the more generic "service manager".
Also:
- use oxford comma
- change "employ" to "use" in various places
- change "the init system forwards messages to syslog" to "are forwarded to
syslog". This is done by systemd-journald, so really there is no forwarding,
because systemd-journald just writes them to a file in the common setup,
so let's use the passive form to avoid specifying who does this.
This fixes the PE section documentation in the systemd-stub man page:
for some reason .uname was listed twice, and .sbat was still missing.
Address that.
Also, let's reorder things to to match the "canonical" ordering we also
use for measurement in sd-stub. The order makes sense and there's really
no reason to depart from that here.
Minor other tweaks.
Reverts b6f2e68602, among other things
In principle, arbitrary notifications may be sent via sd_notify. But in
practice, this is not useful at all, since the manager only accepts
notifications from services and ignores anything except a few specific
ones. The others will be logged if debugging is enabled. OTOH, the manager
produces EXIT_STATUS, but nothing in systemd looks at it, which is rather
confusing.
So remove the recommendation to use X_ prefixes, and instead say that other
messages will be ignored. Also, mention that mkosi uses this. Having an example
may be useful to understand what is going on.
Strangely, this is the first reference to mkosi in our man pages. Even more
strangely, debian is the only place which hosts the mkosi man page (among
the sites we have definitions for), so I linked to that version.
The existing signal doesn't say which type of shutdown is going to happen.
With the introduction of soft-reboot, it is useful to have this information
broadcasted, so that clients can choose to do different things based on the
reboot type.
Add a{sv} as the payload so that more metadata can be added later if
needed, without needing to add yet another signal.
Send both old and new signal for backward compatibility, and send the new
one first so that clients can just wait for the first one on both old and
new systems.
If the user does not specify a config file to use, ukify will try looking for one at {/run,/etc,/usr/local/lib,/usr/lib}/systemd/ukify.conf in order and then use the first one found. Also made sure the --config input is a pathlib.Path by specifying its type in its CONFIG_ITEMS entry.
Big cheers to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> for helping!
We basically parsed the RFC3339 format already, except with a space:
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
so now we handle both
2012-11-23 11:12:13.456
2012-11-23T11:12:13.456
as equivalent.
Parse directly-suffixed Z and +05:30 timezones as well:
2012-11-23T11:12:13.456Z
2012-11-23T11:12:13.456+02:00
as they're both defined by RFC3339.
We do /not/ allow z or t; the RFC says
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
syntax may alternatively be lower case "t" or "z" respectively.
This date/time format may be used in some environments or contexts
that distinguish between the upper- and lower-case letters 'A'-'Z'
and 'a'-'z' (e.g. XML). Specifications that use this format in
such environments MAY further limit the date/time syntax so that
the letters 'T' and 'Z' used in the date/time syntax must always
be upper case. Applications that generate this format SHOULD use
upper case letters.
We /are/ in a case-sensitive environment, neither are in wide-spread
use, and "z" poses an issue of whether "todayz" should be the same
as "todayZ" ("today UTC") or an error (it should be an error).
Fractional seconds are limited to six digits (they're nominally
time-secfrac = "." 1*DIGIT
), since we only support 1µs-resolution timestamps, and limit to six
digits in our other sub-second formats.
Parsing
2012-11-23T11:12
is an extension two ways (no seconds, no timezone),
mirroring our "canonical" format.
Fixes#5194
The example was supposed to show how
machine-id/new/machine-id --app-specific/show --app-specific tie together, but
the verb was ommitted.
I also extended the explanation a bit and used long option form in the first
example for more clarity. In the second, more complicated example, the
one-letter form is used for brevity.
Noticed in post-review:
b37e8184a5 (r1315678438)
I'm keeping this as a separate commit. It is the first time version
information is manually added after 6a73a4f7c4
and we might want to revert this later.
If it is null, we get the 'base' param unchanged:
$ build/systemd-id128 show 00000000000000000000000000000001 \
--app-specific=00000000000000000000000000000000
00000000000000000000000000000001
This is not good, because it breaks our promise that the base (usually either
machine-id or boot-id) cannot be derived from the result. Some application
using the library could use a null app id, inadvertently exposing the machine
or boot id. (This could happen because of forgotten initialization, or maybe
because the app id is configurable, and the user configures it wrongly.)
Note: the other way the secret is not exposed:
$ build/systemd-id128 show 00000000000000000000000000000000 \
--app-specific=00000000000000000000000000000002
4f63080959264900b0d88d999dae2d3a
Normally systemd would not allow a null machine-id or boot-id, but we can let
the user do the calculation that if they want to.
https://github.com/systemd/systemd/issues/27514 requested this functionality
among other things, but it is already implemented. The man page was also
missing 'show' in the synopsis, so add that, along with an example.
This tries to add information about when each option was added. It goes
back to version 183.
The version info is included from a separate file to allow generating it,
which would allow more control on the formatting of the final output.
The notice in the man page is removed and the tool is moved into the $PATH.
A compat symlink is provided.
It is fairly widely used now, and realistically we need to keep backwards
compat or people will be very unhappy.
New directive `NFTSet=` provides a method for integrating network configuration
into firewall rules with NFT sets. The benefit of using this setting is that
static network configuration or dynamically obtained network addresses can be
used in firewall rules with the indirection of NFT set types. For example,
access could be granted for hosts in the local subnetwork only. Firewall rules
using IP address of an interface are also instantly updated when the network
configuration changes, for example via DHCP.
This option expects a whitespace separated list of NFT set definitions. Each
definition consists of a colon-separated tuple of source type (one of
"address", "prefix", or "ifindex"), NFT address family (one of "arp", "bridge",
"inet", "ip", "ip6", or "netdev"), table name and set name. The names of tables
and sets must conform to lexical restrictions of NFT table names. The type of
the element used in the NFT filter must match the type implied by the
directive ("address", "prefix" or "ifindex") and address type (IPv4 or IPv6)
as shown type implied by the directive ("address", "prefix" or "ifindex") and
address type (IPv4 or IPv6) must also match the set definition.
When an interface is configured with IP addresses, the addresses, subnetwork
masks or interface index will be appended to the NFT sets. The information will
be removed when the interface is deconfigured. systemd-networkd only inserts
elements to (or removes from) the sets, so the related NFT rules, tables and
sets must be prepared elsewhere in advance. Failures to manage the sets will be
ignored.
/etc/systemd/network/eth.network
```
[DHCPv4]
...
NFTSet=prefix:netdev:filter:eth_ipv4_prefix
```
Example NFT rules:
```
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
}
chain eth_ingress {
type filter hook ingress device "eth0" priority filter; policy drop;
ip saddr != @eth_ipv4_prefix drop
accept
}
}
```
```
$ sudo nft list set netdev filter eth_ipv4_prefix
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
elements = { 10.0.0.0/24 }
}
}
```
This reverts commits 89e73ce86f and
543d2a4d45.
The commit assign "custom" to fixed DUID type 5. When making DUID fully
configurable, the type number should be also configurable. Also, the
fully custom DUID should be acceptable for DHCPv4.
- add reference to the service unit in the man page,
- fix several indentation and typos,
- replace '(uint64_t) -1' with 'UINT64_MAX',
- drop unnecessary 'continue'.
- rename TCPRetransmissionTimeOutSec= -> TCPRetransmissionTimeoutSec,
- refuse infinity,
- fix the input value verifier (USEC_PER_SEC -> USEC_PER_MSEC),
- use DIV_ROUND_UP() when assigning the value.
Follow-ups for 1412d4a4fe.
Closes#28898.
The kernel default for tmpfs mounts is rwxrwxrwt, i.e. world-writable with the
sticky bit set. This makes sense for /tmp and /var/tmp, but less so for other
directories. Users will not use systemd-mount to mount /tmp and /var/tmp, so
the existing behaviour is surprising. The defaults are overriden to the
same defaults we use for "internal tmpfs mounts", i.e. no sticky bit, nosuid,
nodev, and limits of size=10%, nr_inodes=400k.
--tmpfs is new, so we can modify the behaviour without breaking compatibility.
Mount units can do it, but the command line tool cannot, as it needs a
valid 'what'. If --tmpfs/-T if passed, parse the argument as 'where'
and send a literal 'tmpfs' as the 'what' if not specified.
This metadata (EXTENSION_RELOAD_MANAGER) can be set to "1" to reload the manager
when merging/refreshing/unmerging a system extension image. This can be useful in case the sysext
image provides systemd units that need to be loaded.
With `--no-reload`, one can deactivate the EXTENSION_RELOAD_MANAGER metadata interpretation.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
After f582695107, the wrong behavior
occurred when --since= and --lines= are both specified is fixed.
However, it seems that the old behavior is already being somewhat
widely used, and the function itself makes sense, i.e. to allow --lines=
to output the first N journal entries.
Therefore, let's support prefixing the number for --lines= with '+',
and provide such functionality.
Related: #28746
This setting indicates which directories in the target partition
should be btrfs subvolumes. If set, we'll try to create these
directories as subvolumes.
Note that this only works when running as root without --offline,
as mkfs.btrfs does not support creating subvolumes.
This makes tmpfiles, sysusers, and udevd invoked in the following order:
1. systemd-tmpfiles-setup-dev-early.service
Create device nodes gracefully, that is, create device nodes anyway
by ignoring unknown users and groups.
2. systemd-sysusers.service
Create users and groups, to make later invocations of tmpfiles and
udevd can resolve necessary users and groups.
3. systemd-tmpfiles-setup-dev.service
Adjust owners of previously created device nodes.
4. systemd-udevd.service
Process all devices. Especially to make block devices active and can
be mountable.
5. systemd-tmpfiles-setup.service
Setup basic filesystem.
Follow-up for b42482af90.
Fixes#28653.
Replaces #28681 and #28732.
Follow-up for: 947d836a6e
(I guess in the original patch authors usecase the root fs actually
*does* remain in memory, but that's a special case and does not belong
in the man pages this way).
This is a magic string, and we should avoid stepping into the territory
of normal keymap names with that, given that users can pick names
otherwise freely.
Hence, prefix the name with a special char to avoid any namespace
issues.
Follow-up for: #28660
This is a follow-up for #28596.
I think the suggestion to use Type=exec uses too strong wording:
Type=exec has non-trivial drawbacks over Type=simple, and they deserve
to be mentioned.
Hence drop the <emphasis> and turn this around so that Type=exec is
*recommended*, but Type=simple is not expressly discouraged, because
there are plenty reasons to use it.
Add a brief discussion where Type=simple might be preferable.
Also, fix the outright unruth that Type=exec was the "simplest and
fastest", because it certainly is a lot, but not that.
But the directories are changed from /dev/loop/by-ref/ -> /dev/disk/by-loop-ref/
and /dev/loop/by-inode/ -> /dev/disk/by-loop-inode/.
As /dev/loop/ is used by losetup command for other purpose.
See issue #28475.
This effectively reverts commits 9915cc6086,
5022fab15f, and
c0d998248e.
The command is deprecated, as per NEWS of 254. Let's go one step further
and remove it from the help text and man page, so that people are not
inspired to use it at this time anymore.
This is how we usually have done this before: remove it from visibility,
but support it for a while still.
The previous commit extended the accepted format of --tpm2-pcrs to allow
specifying the hash algorithm (i.e. PCR bank) and hash digest value, this
updates the man page with those changes.
--copy-from synthesizes partition definitions from the given image
which are then applied to the repart algorithm. In its most basic
form, this allows copying an image to another device but it can
also be combined with --definitions to copy + add partitions in the
same call to repart.
--oem can be used to only install OEM partitions (usr, verity,
verity-sig, ...). OEM= is used to indicate OEM partitions. If unset,
defaults to !FactoryReset. We also add a credential repart.oem to
allow configuring --oem via a credential.
Let's allow the combination of these two options. When used, repart
will first try to apply the CopyBlocks= behavior. If that's not possible,
it falls back to the CopyFiles= behavior.
This is a first step in being able to also use the partition definition
files shipped in the image to build the image in mkosi instead of having
a separate set of repart definition files to build the image.
The descriptions of various options are reworked: first say what protocol
actually is, i.e. describe what type of notification the manager waits
for. Only after that describe various steps and things the service should
do. Also, apply some paragraph breaks.
Instead of recommending Type=simple, recommend Type=exec. Say explicitly that
Type=simple, Type=forking are not recommended. Type=simple ignores failure in a
way that doesn't make any sense except as a historical accident. We introduced
'exec' instead of changing 'simple' to keep backwards-compatiblity, but
'simple' is not very useful. 'forking' works, but is inefficient: correctly
programming the interface requires a lot of work, and at runtime, the
additional one or two forks are just a waste of CPU resources. Furthermore, we
now understand that because of COW traps, they may also increase memory
requirements. There is really no reason to use 'forking', except if it's
already implemented and the code cannot be changed to use 'notify'.
Also, remove the recommendations to use Type=simple to avoid delaying boot. In
most cases, if the service can support notifications about startup, those
should be done.
Overall, for new services, "notify", "notify-reload", and "dbus" are the
types that make sense.
