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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Otherwise the root filesystem might still be readonly and
systemd-userdbd fails to start.
Explicitly pick systemd-remount-fs.service instead of local-fs-pre.target
to prevent a dependency cycle.
The mkosi Arch CI doesn't work as the keyring package is out
of date and cannot be built due to various build toolchain
issues. Disable the job as it always fails and confuses
submitters.
This reverts commit 6b219b74de53729249956221a971047aab7c96e0.
This commit doesn't look right to me. We have to unmount everything
recursively *before* we MS_MOVE because the MS_MOVE will not get rid of
it for us, and we simply cannot access these mounts after the MS_MOVE is
complete anymore.
This is a fundamental difference between MS_MOVE and pivot_root(). The
latter repivots the entire mount table getting rid of anything outside
of the new root. MS_MOVE otoh just mounts a bunch of mount points to the
top, leaving in place whatever might be underneath it.
Thus, if we go through the MS_MOVE codepath we must unmount everything
explicitly before doing so because otherwise the mounts will be pinned
forever, but be entirely invisble to userspace.
If pivot_root() fails, we'll fall back to switching root via MS_MOVE.
Unlike pivot_root() that won't place the old root fs anyway, but just
hide it. That's problematic during shutdown for example, since after all
we might still want to access it from the exitrd, to disassemble it
properly.
Hence let's make things somewhat systematic: regardless if pivot_root()
or MS_MOVE is used, always make the old root fs show up in the selected
new dir.
Negative flags always raise eyebrows. Let's normalize
SWITCH_ROOT_SKIP_RECURSIVE_RUN to become SWITCH_ROOT_RECURSIVE_RUN, i.e.
make recursive behaviour opt-in, rather than opt-out. We only want it
for the initrd→host transition, and in all other cases we'd prefer to
avoid it.
This allows us to simplify some code. Also, normalize the mount point
table in switch_root() a bit, to be static const, and then just select
between two mount flag sets via SWITCH_ROOT_RECURSIVE_RUN, where the
mount flag without MS_BIND (i.e. zero) just means "skip this entry".
This does not actually change anything in behaviour, it's just
refactoring.
Follow-up for: b12d41a8bb7c99f7d7a1c7821a886d98b42d9ce0
I'm keeping this as a separate commit. It is the first time version
information is manually added after 6a73a4f7c466887a03c9939300ba6864203b1b3f
and we might want to revert this later.
If it is null, we get the 'base' param unchanged:
$ build/systemd-id128 show 00000000000000000000000000000001 \
--app-specific=00000000000000000000000000000000
00000000000000000000000000000001
This is not good, because it breaks our promise that the base (usually either
machine-id or boot-id) cannot be derived from the result. Some application
using the library could use a null app id, inadvertently exposing the machine
or boot id. (This could happen because of forgotten initialization, or maybe
because the app id is configurable, and the user configures it wrongly.)
Note: the other way the secret is not exposed:
$ build/systemd-id128 show 00000000000000000000000000000000 \
--app-specific=00000000000000000000000000000002
4f63080959264900b0d88d999dae2d3a
Normally systemd would not allow a null machine-id or boot-id, but we can let
the user do the calculation that if they want to.
No functional change. In config_parse_address_generation_type() we would set
the output parameter and then say it's ignored, so it _looked_ like an error in
the code, but the variable was always initialized to SD_ID128_NULL anyway, so
the code was actually fine.
This reverts commit 4ccd48cb2693a3603f14a30b6286228597285d92.
From RFC 4861 section 4.2.
> The Router Lifetime applies only to the router's usefulness as a default
> router; it does not apply to information contained in other message fields
> or options. Options that need time limits for their information include
> their own lifetime fields.
Hence, based on the lifetime field of the message header, we should not
drop any other information.
Note that, in ndisc_router_process_default(), we have already dropp the
default gateway when the lifetime is zero. Hence, we can safely drop the
change.
If there are no "ManagedOOMSwap" entries to monitor, then the event source
can be completely disabled. This scenario appears to be common and avoiding
the wake-ups can save idle energy consumption.
This was discovered while using Sysprof for various GNOME 45 performance
tuning. systemd-oomd goes from waking up a few times a second to no
wake-ups helping keep a laptop in deep(er) sleep.
Signed-off-by: Christian Hergert <chergert@redhat.com>
The type of a file descriptor is `int`, not `pid_t`. This should not
have any effects on API consumers as `pid_t` is already typedef'd as
`int` on all glibc-based systems.
The enum definition, the two string tables and the test all were using
different orders (and in case of the test even missed entries).
Let's unify this, and make sure we always use the same order. This
settles the confusion, and makes the order used for the unicode string
table the canonical one, adjusting the other lists to match it. And adds
the missing entries to the tets.
The monotonic clock value consistency should only be checked if the boot
ID is the same as the last journal entry, and requiring that the current
boot ID be the same as the boot ID of the last entry is not necessary
for ensuring deterministic bisection as we already enforce strict
ordering of the real time clock value in a single journal file.
This fixes an issue where a new journal file is unnecessarily created
every boot, potentially wasting storage space.
With the old boot ID update behavior there's no way to compare the boot
ID of a new entry to be written with the boot ID of the last entry in
the journal in a performant manner, and therefore no way to determine if
monotonic clock value consistency checking is needed. Refuse to open
journal files without the new boot ID update behavior guarantee to
simplify consistency checking.
Previously we only logged our measurements to the journal. This is not a
great solution though, since regular logs are subject to rotation, which
is something we really cannot have for measurements (as it means we can
never reproduce the PCR values from the data). Hence, let's maintain an
explicit log.
Ideally, we'd just use the TCG Canonical Event Log format 1:1
(https://trustedcomputinggroup.org/resource/canonical-event-log-format/).
However it's not a perfect fit fo us, for various reasons. But let's
follow it (in its JSON incantation) as closely at it makes sense, so
that it can easily be converted to the full format by programs consuming
it.
Code comments explain where we deviate from the TCG CEL-JSON, and what
to do about it when reading the data.
After b2851e8d6287ab9bb3cd6e42395271c45ce0e377, if IAID and DUID are not
set on start, calling sd_dhcp_client_set_iaid_duid_en() in
client_message_init() triggers assertion, as the client is already
running at the stage. Let's set IAID and DUID earlier.
Fixes#28990.
