In all other cases we have the older variant before the newer. And since we
generate some documentation tables from the header, this order is also visible
for users. Let's restore the order. This commit does
4565246911 in a slightly different fashion.
This documents that explicit `Before=`/`After=` dependencies can be
used to selectively override implicit ordering coming from default
dependencies. That allows for more granular control compared to the
already documented `DefaultDependencies=no` option.
The alternative approach came up in a discussion around the ordering
of `boot-complete.target`, so this also adds an explicit suggestion
in that direction to the "Automatic Boot Assessment" documentation.
Ref: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048330.html
- Extra memory because ASAN needs it
- The environment variables to make the sanitizers more useful
- LD_PRELOAD because the ASAN DSO needs to be the first in the list
- The sanitizer library packages
- Disable syscall filters because they interfere with ASAN
- Disable systemd-hwdb-update because it's super slow when systemd-hwdb
is built with sanitizers
- Take the value for meson's b_sanitize option from the SANITIZERS
environment variable
This imports credentials also via SMBIOS' "OEM vendor string" section,
similar to the existing import logic from fw_cfg.
Functionality-wise this is very similar to the existing fw_cfg logic,
both of which are easily settable on the qemu command line.
Pros and cons of each:
SMBIOS OEM vendor strings:
- pro: fast, because memory mapped
- pro: somewhat VMM independent, at least in theory
- pro: qemu upstream sees this as the future
- pro: no additional kernel module needed
- con: strings only, thus binary data is base64 encoded
fw_cfg:
- pro: has been supported for longer in qemu
- pro: supports binary data
- con: slow, because IO port based
- con: only qemu
- con: requires qemu_fw_cfg.ko kernel module
- con: qemu upstream sees this as legacy
The "Networking" section has a lonely single document listed right now,
even though the "Concepts" section has two more network related docs.
Move them over, let's end this loneliness.
A few related changes: be explicit that 'main' is the branch we're referring
to. There was a case recently of somebody rebasing on 'master' by mistake.
It's better to be explicit, since 'main' is still not the default for git
(AFAIK).
Also, github seems to send mails about force-pushes, so drop that as a
justification. Commenting about changes that were done is useful even if
github were to send a notification.
And finally, $subject. We do that ourselves, but outside contributors might not
know that that's expected.
The documentations dark-mode background color as
added in #23417 was perceived to be too purple-y [1]
and is therefore replaced by a desaturated black
that is derived from the systemd brand-black using
12% less HSL saturation.
[1] https://github.com/systemd/systemd/pull/23417#issuecomment-1146323820
I reordered the component list to match chronological order: we first install
an entry, then boot it, then the checks happen, etc. Before it was
ordered by "importance", but that is harder to follow.
The boot-counting file-renaming entry-sorting part that the boot
loader implements is moved to the main document. The second document
describes a specific implementation that is provided through systemd
units.
The sorting algorithm is extended to say that bad entries should
be sorted later.
I also added a note that bad entries should be available for booting.
For some reason, the second document said that it applies only to EFI systems.
AFAIK there are no implementations for non-EFI, but the specification should
work just fine, if somebody were to implement it. So that part is dropped.
Fixes#23345.
Sadly, bootctl doesn't implement sorting of boot entries with counting :((((
But I'm leaving that for another PR.
The text used was originally written for everything being on the ESP. It was
later generalized for support XBOOTLDR, and "$BOOT" was introduced to mean
something like "XBOOTLDR if present, the ESP otherwise", and most of the text
was changed to talk about $BOOT. Sadly, this doesn't work, because the two
partitions are not interchangeable. sd-boot loads entries from both partitions,
and its configuration, random-seed, etc. only from the ESP.
The terms are redefined: $BOOT now means either the ESP or the "boot partition"
playing the same role on MBR systems, and $XBOOTLDR is XBOOTLDR.
Like various previous commits, this makes the specification describe our
current implementation.
Also, the let's just accept the common practice of using /boot and /boot/efi.
Since both partitions need to be read to gather configuration, it isn't a
problem that one is mounted underneath the other one. I think having /boot and
/efi is OK, but not better in any measureable way, so let's stop trying to push
people towards this setup.
A note that XBOOTLDR must be on the same disk as ESP is added.
We said "`$BOOT/loader/` is the directory containing all files needed
for Type #1 entries" which is blatantly wrong. And also saying that we
define two directories, /loader and /loader/entries, but only ever defining
the second one was not very consistent.
Instead, let's say that /loader/ is for "boot loader configuration", and
/loader/entries has the snippets. A new section about /<entry-token>/<version>/
is added. This is described as the "recommended layout for additional files".
Also, we said that ID= should be used in the file name, but in fact it
wasn't in the example that was given, and afaik, nobody ever did that. So
this part is reduced to say "kernel version (as returned by `uname -r`,
including the OS identifier)". AFAIK, all distros include some form of
OS identifier in the version, so this should be good enough.
Since we now don't depend on autodetection (e.g. with entry-token and layout
configured), the installed doesn't need to always create /loader/entries and
things will still work. So don't say that the installer needs to create it.
Part of the discussion is moved to the Discussion section.
Overall, this brings the specification more in line with actual practice.
I tried not to introduce any semantic changes, but to reorder the whole
text to be more usable as a reference specification: more sections are
created and the discussion and justifications are moved to the end.
Also, "BIOS" is changed to "firmware" in various places, and other parts
of the text that made sense when this was originally written are now dated
are adjusted. I separated and extended the examples a bit.
The abstract at the top ("TL;DR: Currently there’s no common boot scheme…")
is dropped. It didn't seem to fit anywhere.
Let the table span more than the default content width,
if the table contains alot of data (controlled by width: auto)
(720px is very good for continuous text, but too narrow for tables).
The container class is therefore adapted to put the
width restriction on the elements itself, allowing for
exceptions for individual elements like <table> and
<h1> (which used an offset margin before and is now
streamlined to use a max-width as well).
Also add a striped background to ease reading rows
and allow for horizontal mobile scrolling without
overflowing the entire document, only the table itself.
The format described by this document is used not only for coredumps,
but also for other purposes, so we've outgrown the old title.
A redirect was added based on https://codepo8.github.io/github-redirection-demo/.
I tried to use a relative link, but it's hard to test if it works
before merging.
Co-authored-by: Benjamin Franzke <benjaminfranzke@googlemail.com>
All wiki pages that contain a deprecation banner
pointing to systemd.io or manpages are updated to
point to their replacements directly.
Helpful command for identification of available links:
git grep freedesktop.org/wiki | \
sed "s#.*\(https://www.freedesktop.org/wiki[^ $<'\\\")]*\)\(.*\)#\\1#" | \
sort | uniq
* Avoid traling slash as most links are defined without.
* Always use https:// protocol and www. subdomain
Allows for easier tree-wide linkvalidation
for our migration to systemd.io.
* Use brand-green for demo log messages on the startpage
instead of the default `green` color defined by the browser vendor
(after all, the brand green color is intended to reflect the
boot status output)
* Add a matching blue intro color (mixed using HSL from brand-green
by 55deg hue rotation and 4% lightness)
* Use a defined font-size
(to avoid blurry rendering at 13.33333px, due to font-size: smaller)
* Add possibility for the browser to show horizontal scrollbar
(avoid overflow in mobile view)
Respect the user agent property `prefers-color-scheme` by
rendering the documentation in dark mode, if requested.
Reorganise CSS to store the color palette into CSS variables
and reference these from another set of CSS variables that
are dynamically switched based on the prefers-color-scheme
media query.
Light mode variables stay they same as before,
but to ease color mixing, the current RGB values
have been transformed to HSL (using chrome devtools).
The current body background is now --sd-gray-extralight,
the current body color is now --sd-gray-extradark.
Other gray-variations, needed for dark-mode constrasts
are derived from these colors using HSL lightness shifting.
The systemd brand black color is used as dark mode background
and a matching extralight gray font color has been selected.
The link font-weight is reduced to 400 in dark mode,
as the green color on dark ground becomes to overwhelming
with a bold font.
The systemd logo color is dynamically swapped by using
the special fill value `currentColor` for dark/light-mode
depending parts – as per specification on brand.systemd.io
* 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.
