IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* 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*.)
