* Update to rougify 3.26.1 styling
* Adapt background overwrite by removing default background color
and only adding explicit overwrites for syntax error
(error stylings appear for example in json-excerpts –
see HACKING.md – and are therefore hidden by our css)
* Provides a nice introduction to the intro paragraph
* Ensures text of subpages start at the same position as the intro text
on the homepage
=> less visual "jumps" while navigating
The theme color is used on android to style the chrome
browser-ui with a color that suits the webpage.
Use the dark brand color instead of a random default blue color
in order to fit to the rest of the color scheme.
h1 font weight is defined to be 100 but no font-face
definition for weight 100 is included.
The browser will use the nearest available font-weight
instead. As that is 400, we do specify it explicitly now.
From https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.
I changed the order in the page, but didn't change the text too much. Now the
discussion of the different targets is at the top, and they are ordered like
during boot (network-pre.target first, then network.target, and
network-online.target last). The parts about LSB and $network are pushed down a
bit. I think it is still useful to have them, but not as the main entry point
into the discussion. I tried to clean up the grammar and wording a bit.
One meanigful change is that we now don't say that network-online.target means
interfaces are up and IP addresses have been assigned. In other places we were
saying that the actual implementation is provided by
NetworkManager-wait-online.service, so the actual meaning is not under our
control. The text is changed to say "usually".
The last paragraph is new, I think it's good to say that
"dnf-makecache.service" is fine to use "network-online.target".
We used both "qemu" and "QEMU", let's use the lower-case version everywhere
since it's also the name of the binary and the version that people are
most familiar with.
The stuff under test/ is not only for the integeration tests, but also
for various other test-related stuff, so adjust the docs a bit.
There are some file systems mounted below /sys/ that are not actually
sysfs, i.e. are not arranged in a sysfs/kobject style. Let's refuse
those early. (Example, /sys/fs/cgroup/ and similar.)
(Also, let's add an env var for this, so that it can be turned off for
test cases.)
With meson-0.60, meson compile stopped working with some targets:
$ meson compile -C build update-man-rules
ERROR: Can't invoke target `update-man-rules`: ambiguous name. Add target type and/or path: `PATH/NAME:TYPE`
This is obviously a regression in meson, but based on a chat with the
maintainers, it seems that there's some disagreement as to whether 'meson
compile' is useful and how exactly it should work. Since we're already at
meson 0.60.3 and this hasn't been fixed, and people generally don't seem to
consider this an issue, let's return to documenting the usual practice of
'ninja -C build' that just works everywhere.
(Since nobody has raised any fuss in systemd, it means that people are
generally using the shorter form during development too. I only noticed
because I pasted a command from the release docs when preparing -rc1.)
GIT_VERSION is not available as a config.h variable, because it's rendered
into version.h during builds. Let's rework jinja2 rendering to also
parse version.h. No functional change, the new variable is so far unused.
I guess this will make partial rebuilds a bit slower, but it's useful
to be able to use the full version string.
The test for the variable is added in test-systemctl-enable because there we
can do it almost for free, and the variable is most likely to be used with
'systemctl enable --root' anyway.
The first three fields of a note are binary, so they are subject to
flipping due to endianess. Instead of a stream of bytes, just use
the native 4-bytes type so that it gets encoded automatically.
Implemented in the tools via: https://github.com/systemd/package-notes/pull/31
This new file is supposed to address conflicts with Fedora/Grub's
frankenbootloaderspec implementation, that squatted the /loader/entries/
dir, but place incompatible files in them (that do variable expansion?).
A simple text file /loader/entries.srel shall indicate which spec is
implemented. If it contains the string "type1\n" then the
/loader/entries/ directory implements our standard spec, otherwise
something else.
This allows snippet generators to explicitly order entries: any string
can be set as an entry's "sort key". If set, sd-boot will use it to sort
entries on display.
New logic is hence (ignore the boot counting logic)
sort-key is set → primary sort key: sort-key (lexicographically increasing order)
→ secondary sort key: machine-id (also increasing order)
→ tertiary sort key: version (lexicographically decreasing order!)
sort-key is not set → primary sort key: entry filename (aka id), lexicographically increasing order)
With this scheme we can order OSes by their names from A-Z but then put
within the same OS still the newest version first. This should clean up
the order to match expectations more.
Based on discussions here:
https://github.com/systemd/systemd/pull/22391#issuecomment-1040092633
/dev/urandom is seeded with RDRAND. Calling genuine_random_bytes(...,
..., 0) will use /dev/urandom as a last resort. Hence, we gain nothing
here by having our own RDRAND wrapper, because /dev/urandom already is
based on RDRAND output, even before /dev/urandom has fully initialized.
Furthermore, RDRAND is not actually fast! And on each successive
generation of new x86 CPUs, from both AMD and Intel, it just gets
slower.
This commit simplifies things by just using /dev/urandom in cases where
we before might use RDRAND, since /dev/urandom will always have RDRAND
mixed in as part of it.
And above where I say "/dev/urandom", what I actually mean is
GRND_INSECURE, which is the same thing but won't generate warnings in
dmesg.
00db9a114e ("docs: generate table from header using a script") got the
descriptions for the partition types mixed up. After that change, the
spec claimed, for example, that the /usr partition should contain
"dm-verity integrity hash data for the matching root partition", and
that the /usr verity partition should be of type "Any native, optionally
in LUKS". This made the spec an extremely confusing read before I
figured out what must have happened!
I've gone through the table as it existed prior to 00db9a114e, and moved
the descriptions around in the script that generates the table until
they matched up with what they used to be. Then I regenerated the
table from the fixed script.
This adds a helper script:
$ python3 tools/list-discoverable-partitions.py <src/shared/gpt.h
<!-- generated with tools/list-discoverable-partitions.py -->
| Partition Type UUID | Name | Allowed File Systems | Explanation |
|---------------------|------|----------------------|-------------|
| _Root Partition (Alpha)_ | `6523f8ae-3eb1-4e2a-a05a-18b695ae656f` | [Root Partition] | [Root Partition more] |
| _Root Partition (ARC)_ | `d27f46ed-2919-4cb8-bd25-9531f3c16534` | ditto | ditto |
...
The output can be pasted into the markdown file. I think this works better than
trying to match the two lists by hand.
When user and network namespaces are enabled, the kernel
makes the global keys read-only, and makes the namespaced
ones available for the guest already.
The discovery partitions spec so far suggested we should define
arch-specific partition type uuids only for archs that have EFI. Let's
change that and invite people to define them for any arch. Why? Even if
GPT is defined as part of the UEFI spec it's quite useful independently
of it, too. Specifically, our image dissection logic makes use of it,
i.e. systemd-nspawn, systemd-gpt-auto-generator, systemd-repart,
RootImage=, portable services, and so on. None of these tools are
related to UEFI in any way.
Hence, let's open this up.
When using "capture : true" in custom_target()s the mode of the source
file is not preserved when the generated file is not installed and so
needs to be tweaked manually. Switch from output capture to creating the
target file and copy the permissions from the input file.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This introduces `ExitType=main|cgroup` for services.
Similar to how `Type` specifies the launch of a service, `ExitType` is
concerned with how systemd determines that a service exited.
- If set to `main` (the current behavior), the service manager will consider
the unit stopped when the main process exits.
- The `cgroup` exit type is meant for applications whose forking model is not
known ahead of time and which might not have a specific main process.
The service will stay running as long as at least one process in the cgroup
is running. This is intended for transient or automatically generated
services, such as graphical applications inside of a desktop environment.
Motivation for this is #16805. The original PR (#18782) was reverted (#20073)
after realizing that the exit status of "the last process in the cgroup" can't
reliably be known (#19385)
This version instead uses the main process exit status if there is one and just
listens to the cgroup empty event otherwise.
The advantages of a service with `ExitType=cgroup` over scopes are:
- Integrated logging / stdout redirection
- Avoids the race / synchronisation issue between launch and scope creation
- More extensive use of drop-ins and thus distro-level configuration:
by moving from scopes to services we can have drop ins that will affect
properties that can only be set during service creation,
like `OOMPolicy` and security-related properties
- It makes systemd-xdg-autostart-generator usable by fixing [1], as obviously
only services can be used in the generator, not scopes.
[1] https://bugs.kde.org/show_bug.cgi?id=433299
… but only for a single variable.
The guidelines already allowed declaring variables at the point of
initialization. But not making a function call to do that. Let's allow that
now. The existing style of declaring and initializing seperate is still
allowed, and whatever makes most sense should be used.
This is useful since certain shares can only be mounted with additional
mount flags. For example the SMB share in modern AVM Fritz!Boxes
requires "noserverino" to be set to work from Linux.
Allow specifying CIFS services in the format //host/service/subdir/… to
allow multiple homedirs on the same share, and not in the main dir of
the share.
All other backends allow placing the data store at arbitrary places,
let's allow this too for the CIFS backend. This is particularly useful
for testing.
mkosi automatically builds for the host distro which seems a much
better default to encourage since dnf won't be installed on any host
system that's not Fedora anyway.
This is supposed to be used by package/image builders such as mkosi to
speed up building, since it allows us to suppress sync() inside a
container.
This does what Debian's eatmydata tool does, but for a container, and
via seccomp (instead of LD_PRELOAD).
Those were added in b41a3f66c9 without
an explicit license, so they are under the default license. Some files
already got a header previously, so this only touches the remaining.
The same should be done for docs/_data/extra_pages.json, but it's json, and
json doesn't allow comments.
This adds support for dm integrity targets and an associated
/etc/integritytab file which is required as the dm integrity device
super block doesn't include all of the required metadata to bring up
the device correctly. See integritytab man page for details.
I have no idea if this is going to cause rendering problems, and it is fairly
hard to check. So let's just merge this, and if it github markdown processor
doesn't like it, revert.
With this change, "mkosi build" will automatically build systemd for the
current distro without any further configuration. If people want to do a
cross-distro build by default, they can still create mkosi.default, but I
assume that this is relatively rare.
If people have symlinked mkosi.default to one of the files in .mkosi/, they'll
need to adjust the symlink.
(Building without configuration would always fail, since systemd has many many
required dependencies. I think it's nicer to do the most commonly expected
thing by default, i.e. rebuild for the current distro.)
Mkosi is nowadays packaged for most distros, so recommend installing of distro
packages as the primary installation mechanism.
The verity partition types are per-architecture already, and they contain the
hash data independently of whether we are on a given architecture. (Or in other
words, we would make *use* this partition on some architecture, but the
contents always *exists*.)
This moves the /var/log/README content out of /var and into the
docs location, replacing the previous file with a symlink
created through a tmpfiles.d entry.
If the auto-discovered swap partition is LUKS encrypted, decrypt it
automatically.
This aligns with the Discoverable Partitions Specification, though I've
also updated it to explicitly mention that LUKS is now supported here.
Since systemd retries any key already in the kernel keyring, if the swap
partition has the same passphrase as the root partition, the user won't
be prompted a second time for a second passphrase.
See https://github.com/systemd/systemd/issues/20019
This reverts commit cb0e818f7c.
After this was merged, some design and implementation issues were discovered,
see the discussion in #18782 and #19385. They certainly can be fixed, but so
far nobody has stepped up, and we're nearing a release. Hopefully, this feature
can be merged again after a rework.
Fixes#19345.
"Update about" is not gramatically correct. I also think saying "Record" makes
this easier to understand for people who don't necessarilly know what UTMP is.
Say that r should be declared at the top of the function.
Don't say that fixed buffers result in truncation, right after saying that they
must only be used if size is known.
Adjust order of examples to be consistent.
This catches up homed's FIDO2 support with cryptsetup's: we'll now store
the uv/up/clientPin configuration at enrollment in the user record JSON
data, and use it when authenticating with it.
This also adds explicit "uv" support: we'll only allow it to happen when
the client explicity said it's OK. This is then used by clients to print
a nice message suggesting "uv" has to take place before retrying
allowing it this time. This is modelled after the existing handling for
"up".
This allows to limit units to machines that run on a certain firmware
type. For device tree defined machines checking against the machine's
compatible is also possible.
See https://bugzilla.redhat.com/show_bug.cgi?id=1893417 for the back story:
the fallback hostname matters a lot in certain environments. Right now the only
way to configure the fallback hostname is by recompiling systemd, which is
obviously problematic in case when the fallback hostname shall differ between
different editions of the same distro that share a single compiled rpm.
By making this overridable through an envvar, we're providing an escape hatch
without making this a top-level api. Later on a way to set this through
os-release is added, but I think the approach with the variable is still
useful. It it very convenient for testing, or to override settings only in a
particular service, etc.
This updates the docs about using fdisk/gdisk to make partitions with the right
partition type UUID as defined in the discoverable partitions spec.
Improve wording/grammar/formatting, and reflect that gdisk supports this as
well nowadays; see https://www.rodsbooks.com/gdisk/revisions.html
The wiki was slightly stale, and almost all the information there
was already present in the man page. I moved the remaing part (discussion)
into the man page and adjusted all links to point to the man page instead.
daemon(7) has a some examples of packaging scriptlets… I don't think it fits
there very well. Most likely they should be moved to systemd.preset(5) or maybe
even removed, but I'm leaving that for later.
Very old versions of meson did not include the subdirectory name in the
target name, so we started adding various "top-level" custom targets in
subdirectories. This was nice because the main meson.build file wasn't
as cluttered. But then meson started including the subdir name in the
target name. So let's move the definition to the root so we can have all
targets named uniformly.
While it's perfectly possible today to completely rely on mkosi for
building and testing systemd, to get code completion and other IDE
niceties to work properly, it's still necessary to build systemd
locally.
Recently, mkosi gained the ability to allow external programs to
communicate with the build script. We can use this feature to run
the clangd language server in the mkosi build image via a custom
build script to provide IDE features in editors without requiring
developers to build systemd on the host or install any of systemd's
build dependencies locally.
This commit adds the necessary information on how to set this up
to HACKING.md.
This adds the support for veritytab.
The veritytab file contains at most five fields, the first four are
mandatory, the last one is optional:
- The first field contains the name of the resulting verity volume; its
block device is set up /dev/mapper/</filename>.
- The second field contains a path to the underlying block data device,
or a specification of a block device via UUID= followed by the UUID.
- The third field contains a path to the underlying block hash device,
or a specification of a block device via UUID= followed by the UUID.
- The fourth field is the roothash in hexadecimal.
- The fifth field, if present, is a comma-delimited list of options.
The following options are recognized only: ignore-corruption,
restart-on-corruption, panic-on-corruption, ignore-zero-blocks,
check-at-most-once and root-hash-signature. The others options will
be implemented later.
Also, this adds support for the new kernel verity command line boolean
option "veritytab" which enables the read for veritytab, and the new
environment variable SYSTEMD_VERITYTAB which sets the path to the file
veritytab to read.
Sometimes, non-ramfs initrd root are useful. Eg, for kdump, because
initramfs is memory consuming, so mount a compressed image in earlier
initrd, chroot into it then let systemd do the rest of job is a good
solution.
But systemd doesn't recognize the initrd environment if rootfs is not a
temporary fs. This is a reasonable check, because switch-root in initrd
will wipe the whole rootfs, will be a disaster if there are any
misdetect.
So extend SYSTEMD_IN_INITRD environment variable, now it accepts boolean
value and two extra keyword, "auto" and "lenient". "auto" is same as
before, and it's the default value. "lenient" will let systemd bypass
the rootfs check.
The boot loader specification link points to the boot loader interface
documentation.
This fixes the link to point to BOOT_LOADER_SPECIFICATION instead of
BOOTLOADER_INTERFACE which is itself.
This only changes documentation. In various places we call "ninja"
directly. I figured it would be safer to leave those in place for now,
given the meson replacement commands lines appears to be supported in
newer meson versions only.
FixedRandomDelay=yes will use
`siphash24(sd_id128_get_machine() || MANAGER_IS_SYSTEM(m) || getuid() || u->id)`,
where || is concatenation, instead of a random number to choose a value between
0 and RandomizedDelaySec= as the timer delay.
This essentially sets up a fixed, but seemingly random, offset for each timer
iteration rather than having a random offset recalculated each time it fires.
Closes#10355
Co-author: Anita Zhang <the.anitazha@gmail.com>
