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 6b219b74de.
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: b12d41a8bb
I'm keeping this as a separate commit. It is the first time version
information is manually added after 6a73a4f7c4
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 4ccd48cb26.
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.
