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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
file-hierarchy does not mention anything about the expected mountpoint
for cgroups. This may lead some software to believe it will need to
search for it (e.g. by scanning mountinfo) rather than just looking in
the canonical location.
Document the canonical mountpoint as /sys/fs/cgroup. Also provide
information on the non-default configurations, but
make it clear that in such configurations if cgroup2 is mounted (hybrid
mode) it won't have resource controllers attached. This will help
software know if it should fall back to /sys/fs/cgroup/unified or just
ignore that case.
(cherry picked from commit c8aeb9d672fac7ac2d1e350431b7b4e734b90a5d)
Python gained support for reading os-release, let's advertise it a bit more.
Our open-coded example is still useful, but let's not suggest it as the
default implementation.
I added quotes around the printed string because it looks a bit better
this way.
(cherry picked from commit ee6fd6a50922d2b27c97084e1c3f9872d495c273)
It turns out we can't have an Example nested in a list, and every
combination of nesting I tried looked bad either in troff or in html.
The whole example is moved to a separate section.
(cherry picked from commit e6ce19516315138d983ed4b7776d9ebd2fb296d8)
glibc now has Suggests:glibc-minimal-langpack, so we don't
need to mention it ourselves.
--repo=… is a nicer alternative to --disablerepo=* --enablerepo=….
It also avoids the issue with quoting.
Let's exclude weak deps, but install systemd-networkd, so the container
can configure networking if necessary.
(cherry picked from commit 8c4db5629c877425b2f46e414a94a8f24280a9d3)
Since kernel 5.17-rc1, 5.16.3, and 5.15.17 (more specifically,
8dce439195)
the kernel refuses to create an xfrm interface with zero ID.
(cherry picked from commit fd11005951920a0cee96f0c56f36d9ff8bc66a41)
I hope that this fixes the comment
https://github.com/systemd/systemd/pull/22141#issuecomment-1013960371
> As someone who doesn't know what this prog does
The listing in the man page is sorted according to logical
use: all the options setting the address are now together.
(cherry picked from commit b7bb58ef70b0c876941a1c31ed4e2f5f1dc5ed0e)
Follow-up for 0bc488c99ab2ed3464237607e381f4d72cd321d5.
Also sort dependency properties to make them match the definition of
`enum UnitDependency` in basic/unit-def.h.
Fixes#22133.
(cherry picked from commit adc1b76c30940da2f3fb11275f5b0e54ebbcd7f1)
RouteTable=off was introduced to provide consistency with wg-quick
command. This makes the RouteTable= settings accepts other negative
boolean values.
(cherry picked from commit e135559d805e749a0a1f8d1396cf71f6edd94831)
In particular, mention the contract the generator has with external
ExecCondition= binaries that may be provided by desktop environments.
But, also mention all the other relevant keys. In particular
X-systemd-skip= is important to be documented.
(cherry picked from commit 048d46999995847095e3b7a513ba0627e0179dec)
* sd-bus/man: document EBUSY error in bus_message_read
The EBUSY error can be returned from sd_bus_exit_container(), and, if
that happens, it will be propogated upwards towards bus_message_read. In
terms of documentation, this means that bus_message_read's man page
can't just include the error text for sd_bus_message_read_basic, as
reading basic types exclusively doesn't have the potential for this
error.
sd_bus_message_read_basic's error documentation isn't incorrect when
applied to sd_bus_message_read, it's just incomplete. While EBUSY is
documented in sd_bus_message_open_container.xml,
it's explanation is unique to the sd_bus_message_exit_container function
and makes for poor documentation of the general read API.
(cherry picked from commit a1a03fa54bfb45315eefaa49ceb38a21aceafde8)
Also fixes the following:
- IPServiceType= is moved to [DHCPv4] section,
- drop an incorrect sentence in RouteMTUBytes= in [DHCPv4] section.
- drop unnecessary word 'unsigned'.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2006761:
> systemd-resolved always (reverse)-resolves the host's IP addresses and FQDN.
> This can be harmful when an application (for instance, a DNS zone manager) is
> installed on the same server instance. That application would expect
> NXDOMAIN to be returned if the current server's IP does not belong in an
> already managed reverse zone.
This allows clients of nss-resolve to use the same config options that are
available through the dbus api and as command-line options to resolvectl.
The man page text is is mostly copied directly from
c6f20515ab600098b5c2871bae2e9ecab3b41555.
Spotted whilst debugging:
```
[763/2094] Generating man/machine-info.html with a custom command
Element cite in namespace '' encountered in para, but no template matches.
[765/2094] Generating man/machine-info.5 with a custom command
Element cite in namespace '' encountered in para, but no template matches.
```
Follow-up to 357376d0bb5.
Now that kernel-install creates the machine-id directory, we don't need to do
this is 'bootctl install', and in fact it's better not to do this since it
might never be necessary. So let's change the default behaviour to 'no'.
I kept support for 'auto' to maintain backwards compatibility, even though the
default was changed. Previous behaviour can be requested by specifying
--make-machine-id-directory=auto.
341890de866f2ee34919a47ce3fc6c8cd3c1924c made "bootctl install" create
ESP\MID, in preparation of cf73f650890b56a59bfb713c4c82b4e29daa7316 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b552e113bd3d44355b237c41e42beb58 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
If KERNEL_INSTALL_MACHINE_ID is defined in /etc/machine-info, prefer it
over the machine ID from /etc/machine-id. If a machine ID is defined in
neither /etc/machine-info nor in /etc/machine-id, generate a new UUID
and try to write it to /etc/machine-info as KERNEL_INSTALL_MACHINE_ID
and use it as the machine ID if writing it to /etc/machine-info succeeds.
In practice, this means we have a more robust fallback if there's no
machine ID in /etc/machine-id than just using "Default" and allows
image builders to force kernel-install to use KERNEL_INSTALL_MACHINE_ID
by simply writing it to /etc/machine-info themselves.
The ordering of the service wrt. to udevd is enforced by unit configuration,
so no need to tell the user about this. From users' POV, the only thing that
counts is that the unit is enabled and then the right thing happens.
This description will help users who are trying to reset the already configured
CPUQuota= by trying incorrect ways such as CPUQuota=0 or CPUQUota=infinity.