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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The systemd-pstore service takes pstore files on boot and transfers them
to disk. It only does it once on boot and only if it finds any. The typical
location of the pstore on modern systems is the UEFI variable store.
Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the
UEFI variable store is only available on boot after the respective module
is loaded.
In most situations, the pstore service gets loaded before the UEFI pstore,
so we don't get to transfer logs. Instead, they accumulate, filling up the
pstore over time, potentially breaking the UEFI variable store.
Let's add a service dependency on any kernel module that can provide a
pstore to ensure we only scan for pstate after we can actually see pstate.
I have seen live occurences of systems breaking because we did not erase
the pstates and ran out of UEFI nvram space.
Fixes https://github.com/systemd/systemd/issues/18540
Increase the log severity in case of writing to a non existent sysctl
parameter as this can either be caused by a misspelling or a kernel mis-
configuration, e.g. in case YAMA does not get loaded due to a incomplete
lsm= override:
systemd-sysctl[354]: Couldn't write '1' to 'kernel/yama/ptrace_scope', ignoring: No such file or directory
`global` is needed only when assigning a new value to the global
variable; it's not necessary when modifying a mutable object (in our
case we just append items to the global list).
dns_label_unescape() does not nul-terminate the buffer if it does not
have enough space. Hence, if a lable is enough long, then strjoin()
triggers buffer-overflow.
Fixes#23705.
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 think developers are particularly unlikely to find the descriptions
useful, and would benefit from being able to copy&paste unit names.
Let's make this choice automatically.
