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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This adds two more phases to the PCR boot phase logic: "sysinit" +
"final".
The "sysinit" one is placed between sysinit.target and basic.target.
It's good to have a milestone in this place, since this is after all
file systems/LUKS volumes are in place (which sooner or later should
result in measurements of their own) and before services are started
(where we should be able to rely on them to be complete).
This is particularly useful to make certain secrets available for
mounting secondary file systems, but making them unavailable later.
This breaks API in a way (as measurements during runtime will change),
but given that the pcrphase stuff wasn't realeased yet should be OK.
This fixes a regression introduced in e1636807 that removed setting this
value as it seemingly was not used by the kernel and would actively
break above 4G boots. But old kernels (4.18 in particular) will not boot
properly if it is not filled out by us.
The original issue was using the truncated value to then jump into the
kernel entry point, which we do not do anymore. So setting this value
again on newer kernels is fine.
The function for handling regular mounts based on DissectedPartition
objects is called add_partition_mount(), so let's follow this scheme for
all other functions that handle them, too. This nicely separates out the
low-level functions (which get split up args) from the high-level
functions (which get a DissectedPartition object): the latter are called
add_partition_xyz() the former just add_xyz().
This makes naming a bit more systematic. No change in behaviour.
Try harder to inherit the sequence number and ID from the old journal
file before rotating it away.
This helps the libsystemd journal file selection code make better decisions
even in the face of massive incorrect forward clock jumps prior to an
unclean shutdown.
We list plenty of arch-specific syscalls in our filter groups, treat the
s390 syscalls the same.
We handle gracefully anyway if some syscall doesn't exist locally on the
kernel or arch, let's rely on it. This has the benefit that
"systemd-analyze" will comprehensively tell you the syscalls filtered on
any arch for any arch.
And less conditionalization is good anyway.
Note --private-key and --certificate options for configuring
verity signature partitions in the listing of options.
Adjust one error message referring to the --certificate option.
Attempt to address
https://github.com/systemd/systemd/issues/20330#issuecomment-1210028422.
Summary of the comment: Unprivileged users can potentially cause a denial of
service during systemd-oomd unit subscriptions by spamming requests to
SubscribeManagedOOMCGroups. As systemd-oomd.service is the only unit that
should be accessing this method, add a check on the caller's unit name to deter
them from successfully using this method.
Using _SOURCE_{MONOTONIC,REALTIME}_TIMESTAMP in place of the results of
sd_journal_get_{monotonic,realtime}_usecs in export formats might cause
internal inconsistency of realtime timestamp values within a journal export,
violating the export file format and causing systemd-journal-remote to
mass-generate journal files.
Fix this by using the real journal timestamps for
__{REALTIME,MONOTONIC}_TIMESTAMP.
Try to separate the description so that changes are described first, and the
discussion follows separately. Remove some repeated verbose descriptions of the
subject: if one sentence describes that UKI contains an signature and describes
it in detail, the next sentence can just say "the signature" without
elaborating. Also, we don't do version-keying yet, so don't say "future"
kernels — older kernels will work too.
If no module name is provided, then try to load modules based on the
device modealias.
Previously, MODALIAS property is passed as an argument, but it may
contain quotation. Hence, unfortunately the modalias may be modified
and cannot load expected modules.
Fixes#24715.
Typically the _MAX and _INVALID special enum values use the full type as
prefix, even if the actual values of the enum might not. Let's follow
this rule here too.
We can just make this an enum, as long as we ensure it has enough range,
which we can do by adding -ERRNO_MAX as one possible value (at least on
GNU C). We already do that at multiple other places, so let's do this
here too.
The uverbs devices are sequentially numbered and are not guarranteed to
stay stable across reboot.
At least one good person was disappointed by this, because they couldn't
find their device: https://bugzilla.redhat.com/show_bug.cgi?id=2036515
Let's add a few helpful links.
'systemctl unmask foo' will try to remove the symlink to /dev/null under /etc/.
But the unit may also be masked by a symlink under /run/generator, in particular
the one created by systemd-debug-generator based on systemd.mask=foo on the
kernel commandline. The unmask call cannot anything about this: even if it removed
the symlink from /run/generator, it'll be recreated on the next daemon-reload.
Thus, we can only warn about it.
Initially, I wanted to check if 'systemctl.mask' is defined on the kernel
command-line, but that's not effective, because such mask symlinks can be
created by other generators based on other conditions. Checking for runtime
mask is "dumber", but is more robust because it doesn't assume who created the
mask and why.
The handling of InstallInfo is the copied from install_info_symlink_wants().
It's pretty ugly, this whole code should be rewritten from scratch.
The message is printed, but the whole operation is still "successful". This
keep backwards compatibility: people might call unmask to remove filesystem
masks even if there's still a cmdline param in place. We allow 'systemctl
mask' to create such a mask, so 'unmask' should be able to remove it.
Fixes#22689.
We had an anonymous enum with values called UNIT_FILE_…, which could easily be
confused with UNIT_FILE_… from UnitFileFlags enum. This commit renames the enum
values and also the variables which refer to them.
