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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I'm not sure what "suffix" was meant by this comment, but the file has the usual suffix.
The file was added with the current name back in c4708f132381e4bbc864d5241381b5cde4f54878.
Maybe an earlier version of the patch did something different.
(cherry picked from commit 9c7188547cd53dddd635c86c8ef5655290541966)
(cherry picked from commit d9abd8babe01ab4e2e6d913d148369ade78441a4)
(cherry picked from commit 2ca2390b113dd45305ff131b74ed39b919931417)
(cherry picked from commit 3339b23f4cde85690fe9f8e0486793b93af12b2f)
An rpminspect test in Fedora/RHEL is flagging our stub files as having an
executable stack. The check is correct:
$ readelf --wide --program-headers build/src/boot/efi/linuxx64.elf.stub | rg -i stack
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10
It seems to be just an omission in the linker script… None of the objects that
are linked into the stub are marked as requiring an executable stack:
$ readelf --wide --sections build/src/boot/efi/*.c.o \
/usr/lib/gnuefi/x64/libgnuefi.a \
/usr/lib/gnuefi/x64/libefi.a \
/usr/lib/gcc/x86_64-redhat-linux/12/libgcc.a \
| rg '.note.GNU-stack.*X'
(nothing)
On aarch64 we end up with a nonexecutable stack, but on ia32 and x64 we get one,
so this might be just a matter of defaults in the linker. It doesn't matter
greatly, but let's mark the stack as non-executable to avoid the warning.
Note: '-Wl,-z' is not needed, things work with just '-z'.
(cherry picked from commit 1eca770933e49a1be16e40bfbaefc0f75af81781)
(cherry picked from commit 44c2ff5b1ebbc0a18c0f3676b7ea3242250315f0)
(cherry picked from commit 4f4344e3a5578b76e83633673cbb3ce368ebd2de)
(cherry picked from commit c68ae31edbcba1e6cb263fdb23efe5130e56ed7b)
(cherry picked from commit 464ec1dec741e31d7bf08a4b7bb5a64a6adbb81d)
(cherry picked from commit eae11e3f064372ec30efe460381ce807238daa82)
(cherry picked from commit 8af5e945c7d489e7cf4c1dd29612e5452122b754)
(cherry picked from commit 73fd23631111ea8daefceeef61fb02bfd4e49b96)
r and R take globs, so let's name the argument appropriately in the tl;dr listing.
Also, use 'clean-up' in the file name where it represents the verb "clean up",
and other minor spelling adjustments.
(cherry picked from commit 164297cd9a410fdd9ca3c068da4d80d74916cf18)
(cherry picked from commit aac692160ef2a88f4a725f7ade900c6bd6b36641)
(cherry picked from commit e72f1676afe4ceae96583e848d023f1b6ec3d6c4)
(cherry picked from commit 88302d7f84a82e544f3b0953fbcd7dc5f8221f5a)
This is useful for debugging issues like #26474.
(cherry picked from commit b9fadf2e2cb83d342342341b0edba4f519890634)
(cherry picked from commit ba1cb4156bb7df9d5ce1b35a25425e544f6989de)
(cherry picked from commit 892fe5d2049b1cb25a523c51518fd66a14642974)
(cherry picked from commit bfbd75cf87441149e4b9add57fbeccfc836dd5de)
Previously, we skip the entries before arg_lines
unconditionally, which doesn't behave correctly
when used with --grep. After this commit, when
a pattern is specified, we don't skip the entries
early, but rely on the count of the lines shown
to tell us when to stop. To achieve that we would
have to search backwards instead.
Fixes#25147
(cherry picked from commit db4691961ca52759fe6645d0fddb659ee4299ac2)
(cherry picked from commit c4cdbb978f681e7356c6c6367c1730d156a6a4e0)
(cherry picked from commit e9889190bea734566e778a60a1dc337e9c7ad18d)
(cherry picked from commit a90a4560ff4ed69d254b20b7418ab31f69c617e6)
The TPM code expects a description unless the PCR index indicates that
no measurements have to take place. The assert was preempting this
check from happening.
Fixes: #26428
(cherry picked from commit f92428eae53685f372775e8cb0f0f4c249f02724)
(cherry picked from commit cd5de2811ae72e209377f714cdbd8e5a0d6361bc)
(cherry picked from commit ac3d8922df1a08de934fc9d8c81cd0215bcb1633)
(cherry picked from commit 2cf90e13f5020f41e0919d4a2d7f181ecce3613d)
(cherry picked from commit 6aa2c55522d7cac62ecfd5d5687a86a84f158d18)
(cherry picked from commit 01b90e1588e29888c7583bd320b898b59257d737)
(cherry picked from commit 7c9b9c8d93b57f06ad1974adfa1fc0e94ac7b405)
(cherry picked from commit 292debc981bbf59ccacaa2bdd391f880af806023)
Follow-up for 29a24ab28e9790680348b1ffab653a321fa49a67.
(cherry picked from commit dbfc096095cb741f5345be0dc6508628008c46d7)
(cherry picked from commit a3177cbe546537c873d477138014d054b1cc6376)
(cherry picked from commit 6e8d76f776b02eadfa6e4575f516866786fd3817)
(cherry picked from commit 4647e869227bec6c495194ed4e49061c141d4a6c)
If UDP is blocked on the system (e.g. by iptables or BPF), the kernel will
return EPERM on some or all of the system calls (connect, sendmsg, etc.).
In this case, try to fall back to TCP, which hopefully will not be blocked.
(cherry picked from commit 3dd6336ad0cb40e928745404ed72c41e4ac9c39e)
(cherry picked from commit a88e35bf953f5a0047d5170d0d0e2d372b2280ae)
(cherry picked from commit 58cbb7a89b1b66be8b593eec29a6413d5ecdb780)
(cherry picked from commit 5f6a369a6a680051872a94e97a3420187901301c)
Follow-up for 49bb7fe5f88fc35b8529d7d8dfcd4c151a9aaf1a.
Fixes an issue reported at
https://github.com/systemd/systemd/pull/26270#issuecomment-1428945403.
(cherry picked from commit 9361a712f85860ead532dba1468dbd3deef00e34)
(cherry picked from commit e91a3042747398475b83ba00915f768e578bb9ff)
(cherry picked from commit f32581ac800467d05325098b9202b2e3cd018c34)
Timestampfs from sysfs files can be zero in which case ERANGE will
be returned so let's make sure we catch that.
(cherry picked from commit 0da4cc97b446b43802692f2415e5a774771b0ca9)
(cherry picked from commit ef96e60f18c6fd267dc0e942120a95fe25a94960)
(cherry picked from commit 18a2aaf2f6c2c55f825632c25b07b121f6a1bb78)
(cherry picked from commit f39d7d00a31c1867d5fa41b3dd4e6d20665a8f3a)
(cherry picked from commit bfaf02348e1086c9ce2e4503ef03dc75ed4f1afb)
(cherry picked from commit 067b5b7e892ffa420628fef026ea4d1e16b2110d)
(cherry picked from commit 7b03b44ed9f5f748670aa26193274dae94468149)
(cherry picked from commit cad1e9c53d7ce0b8e461c094d6244a6409c80ab6)
(cherry picked from commit 3a44be9ad0d9e718c2a79d42d43f2f453b3e6e58)
Inspired by: #26364
(this might even "fix" #26364, but without debug logs it's hard to make
such claims)
Fixes: #23055
(cherry picked from commit 32d6707dd1692d41e12f5469dfdcbc10f14d6619)
(cherry picked from commit c973e2295cdc0fcf63569044ae81e6b93d4f2b4b)
(cherry picked from commit bfe6d1d1979e98ffae0e56e2d2f0a2dda1fe209d)
It allows to relax the checks and allow characters like '\', used by
windows to split the domain name and user name.
For reference, discussion in the systemd-devel mailing list:
https://lists.freedesktop.org/archives/systemd-devel/2023-February/048804.html
Signed-off-by: Samuel Cabrero <scabrero@suse.de>
(cherry picked from commit edd5ec23738ef9ae7b1416bacede97e70ddf9402)
(cherry picked from commit 68d11465e437d1916a5fbe0cd223283050d40ab1)
(cherry picked from commit 132e153b9045c9c88f70cf36115ffefb84adb971)
These are the most visible and hard requirements, as we use options that
busybox does not provide, so list them explicitly to avoid surprises
(cherry picked from commit 164070e497f36b6d8055e4338e07188dd975f6f2)
(cherry picked from commit 0dc9f7335d37be2a90f34e20f04573331bf3e4d3)
(cherry picked from commit facb134183d72c31636f09bcae080cf9337a6877)
We would print "Current command vanished from the unit file, execution of
the command list won't be resumed." as a warning, but most of the time there
is nothing to resume, because a unit has just one command. So let's detect
the case where the command that was active is the last command in the sequence
and skip the warning.
I was considering how to store the information that the command is last. An
important consideration is not to use a format that would confuse older versions
of systemd. (It wouldn't be a big problem if older systemd just refused the
new serialization, since we require systemd to be newer, but we should avoid
the case where the deserialization is "successful", but actually incorrect.)
Similarly, the deserialization from the old systemd must not confuse new systemd.
For this command, we have a list of arguments at the end, so just adding a
new field either in the middle or at the end is problematic because it's hard
to ensure that we don't mix up the positional and variable arguments.
We actually need to store just one bit of information, so '+' is prefixed on
the index of the last command and used by new systemd to skip the warning.
When deserializing from older systemd, '+' is not present, so we detect all
commands as "not last", and still emit the warning, so we err on the side of
caution. If the user were to deserialize from newer to older systemd, nothing
untoward would happen, because the '+' is ignored. (Users shouldn't do this,
but we know that this occasionally happens with initrds or exitrds and package
downgrades.)
(cherry picked from commit a99bd455b59b7922a1b1af480b209263a4d3c659)
(cherry picked from commit 9bb72a4e9694ec301d89861e349eb31fbf1aba16)
(cherry picked from commit a71be850b58bdba2ac11566ee1a268a9b00e36d6)
I expected this to work, but our tests did not cover this
explicitly.
(cherry picked from commit 8eb491f4993c6080e9724c0359a87c64c460605e)
(cherry picked from commit 7c0ac515c8094fd62c100477fa293aa31f97e2c4)
(cherry picked from commit 36c35e765db478d5f72cdd70cd663baa865ad43a)
(cherry picked from commit 502096b56593919fc947415f6e32bcb680728dac)
(cherry picked from commit e811aead84ec71926c4b53756a69f75f5b30aaa8)
(cherry picked from commit b4df64597b48a78028f695e50db9d9e74a3767e6)
If the device access policy is restricted, add implicitly access to the TPM
if at least one encrypted credential needs to be loaded.
Fixes https://github.com/systemd/systemd/issues/26042
(cherry picked from commit 398dc7d39b9a877e71529f0e0b139329e4c6992e)
(cherry picked from commit f0126ad7f90a37c6c81e735726a3bbea1aa6d4d7)
(cherry picked from commit 158760941f6f59f6307a49455ce1af5db97b67c9)
This effectively reverts commit ff86c92e3043f71fc801cf687600a480ee8f6778,
and re-apply 49f3ee7e74c714f55aab395c080b1099fc17f7fd.
The change was dropped due to the process name was not correctly logged,
but the issue was fixed by dd15e4cb57129b915e01495e113696bfe0b70214.
Let's set the child process name again.
(cherry picked from commit e955a7f460adadf54da7bfb62f04cbff16ca5941)
(cherry picked from commit 62055cfd4bf2355abb3c0ccb52a5802b41d0ec92)
(cherry picked from commit a87c01d20246429a53ebfac48e9bdba4eed019f7)
Our logging uses program_invocation_short_name. Without this patch,
logs from forked client may become broken; spuriously truncated or
the short invocation name is not completely shown in the log.
(cherry picked from commit dd15e4cb57129b915e01495e113696bfe0b70214)
(cherry picked from commit ce4726468dc02bd7383cd7d90c8769576c6973e3)
(cherry picked from commit 7a862d9d1a7196a5576720959849f45fc68b041c)
(cherry picked from commit 375ffdba43f6dac5f4b1222d4e345f7cdf868f8c)
(cherry picked from commit 31b7785814fa9e82a1d48e4b5a6b1f6df1110b03)
(cherry picked from commit 828e73a7bb17cf8ec4a0f90004a878fcc839add5)
If any query makes it to the end of install_info_follow() then I think symlink_target is set to NULL.
If that is followed by -EXDEV from unit_file_load_or_readlink(), then that causes basename(NULL)
which segfaults pid 1.
This is triggered by eg. "systemctl status crond" in RHEL9 if
/etc/systemd/system/crond.service
-> /ram/etc/systemd/system/crond.service
-> /usr/lib/systemd/system/.crond.service.blah.blah
-> /usr/lib/systemd/system/crond.service
(cherry picked from commit 19cfda9fc3c60de21a362ebb56bcb9f4a9855e85)
(cherry picked from commit 015b0ca9286471c05fe88cfa277dd82e20537ba8)
(cherry picked from commit 9a906fae890904284fe91e29b6bdcb64429fecba)
(cherry picked from commit 7b2f84e3f2c5cf84ca39a054493979a8960a9d47)
(cherry picked from commit 6d8885af572bfa662bc3b74ebc4831c6e8a155ce)
(cherry picked from commit 3ae34059895a12b99e3f312316f0a0f57d1c5abd)
(cherry picked from commit 17be6f270907eff274df80e91e1d323cb04f266f)
(cherry picked from commit aa79d157af49bc8e5664b881b27057d6bc589633)
(cherry picked from commit 8a91017dad2d741020a8e8c584374ec7a95d7eec)
(cherry picked from commit 3774ff06f25335c2a049585f0ecb486a3da58e5e)
(cherry picked from commit 5bad071f73bab88ee2b7c0891e40e76f8d579755)
(cherry picked from commit 4aa6be359f509eeaf3ded290489136513c24ce2a)
In https://bugzilla.redhat.com/show_bug.cgi?id=2156900 sysusers was reporting a
conflict between the following lines:
u root 0:0 "Super User" /root /bin/bash
u root 0 "Super User" /root
The problem is that those configurations are indeed not equivalent. If group 0
exists with a different name, the first line would just create the user, but the
second line would create a 'root' group with a different GID. The second
behaviour seems definitely wrong. (Or at least more confusing in practice than
the first one. The system is in a strange shape, but the second approach takes
an additional step than is worse than doing nothing.)
When this line was initially added, we didn't have the uid:gid functionality for
'u', so we didn't think about this too much. But now we do, so we should use it.
$ build/systemd-sysusers --root=/var/tmp/inst7 --inline 'g foobar 0'
Creating group 'foobar' with GID 0.
$ build/systemd-sysusers --root=/var/tmp/inst7 --inline 'u root 0 "Zuper zuper"'
src/sysusers/sysusers.c:1365: Creating group 'root' with GID 999.
src/sysusers/sysusers.c:1115: Suggested user ID 0 for root already used.
src/sysusers/sysusers.c:1183: Creating user 'root' (Zuper zuper) with UID 999 and GID 999.
vs.
$ build/systemd-sysusers --root=/var/tmp/inst7 --inline 'u root 0:0 "Zuper zuper"'
src/sysusers/sysusers.c:1183: Creating user 'root' (Zuper zuper) with UID 0 and GID 0.
(cherry picked from commit 49bb7fe5f88fc35b8529d7d8dfcd4c151a9aaf1a)
(cherry picked from commit 8ad3d68acd7202afb35660eea49fe8c9f92609b8)
(cherry picked from commit c8b6bc7530030568bb980a66aa8e1b6517998c58)
Despite popular belief, the default file extracted by GNU tar is not stdin. It
is the value of the TAPE environment variable, falling back on a compile-time
constant. On my system, the default value is /dev/full, which causes tar to
just spin forever due to --ignore-zeros. Always specifying this flag is the
safe thing to do.
~$ tar --show-defaults
--format=gnu -f/dev/full -b20 --quoting-style=escape
--rmt-command=/usr/sbin/grmt
See also: ``(tar)defaults'', available via Info viewers, and in HTML form at:
https://www.gnu.org/s/tar/manual/html_node/defaults.html
(cherry picked from commit 181eea677dd364d2b22dc691647792142b271074)
(cherry picked from commit 817b8441c481cec71689a8ccac727d85e3ba549b)
(cherry picked from commit 48f3e2d5c5cfba01405a609a5bd4d54071243c13)
If we receive a header only message, and the server is running in relay
mode, then the assertion was triggered.
Fixes#26151.
(cherry picked from commit b52031dbbcabe4b1e3016ba64d4a2822740188bc)
(cherry picked from commit 7aeb2a8d4ea660ad863e7b2c5432f64f903f1cd5)
(cherry picked from commit 41fdc8ed32408d598ddafc7feb3beece7f654262)
If we don't have CAP_NET_BIND_SERVICE, we won't be able to bind
the stub listener socket, so let's skip creating it and log a warning.
We do the same for the extra stubs if they're configured on privileged
ports.
(cherry picked from commit 0398c084efba664e44625d82f2be72e18c952678)
(cherry picked from commit ab877f7072728420e49d179bca310a698cf9994c)
(cherry picked from commit 2a36784277756c3a5e424efdd671a7a33bc8e128)
If we're in a user namespace but not unsharing the network namespace,
we won't be able to bind any privileged ports even with
CAP_NET_BIND_SERVICE, so let's drop it from the retained capabilities
so services can condition themselves on that.
(cherry picked from commit 2642d22adc66771bd8bbb4187dc3de5472d04ad6)
(cherry picked from commit 3a49291f4b82e746294df1772e9ab7eb957a9771)
(cherry picked from commit 5037e0d27bc40594f9f7e7298ee38a3540ac4aa8)
Add a test that verifies a deleted alternative name is restored on error
in rtnl_set_link_name().
(cherry picked from commit b338a8bb402a3ab241a617e096b21ae6a7b7badf)
(cherry picked from commit 7299341bd1e114d2ef29539f4b0b5b5da9900120)
(cherry picked from commit 37df773b230cebc65fae045abc6b17f4c1489cab)
If a current alternative name is to be used to rename a network
interface, the alternative name must be removed first. If interface
renaming fails, restore the alternative name that was deleted if
necessary.
(cherry picked from commit 4d600667f8af2985850b03a46357e068d3fb8570)
(cherry picked from commit 42d8817bd652731a25facebb4d6db7ee822774c2)
(cherry picked from commit a536073a62bdc37d6190603bc9f41d364f41387b)
Commit 434a348380 ("netlink: do not fail when new interface name is
already used as an alternative name") added logic to set the old
interface name as an alternative name, but only when the new name is
currently an alternative name. This is not the desired outcome in most
cases, and the important part of this commit was to delete the new name
from the list of alternative names if necessary.
(cherry picked from commit 080afbb57c4b2d592c5cf77ab10c6e0be74f0732)
(cherry picked from commit 3dc5b19f10916e15adb9071057fe877a958daea8)
(cherry picked from commit facb873e6ffe1fd3e2f89cee2ed80756a849460a)
When configuring a link's alternative names, the link's new name to-be
is not allowed to be included because interface renaming will fail if
the new name is already present as an alternative name. However,
rtnl_set_link_name will delete the conflicting alternative name before
renaming the device, if necessary.
Allow the new link name to be set as an alternative name before the
device is renamed. This means that if the rename is later skipped (i.e.
because the link is already up), then the name can at least still be
present as an alternative name.
(cherry picked from commit d0b31efc1ab7f6826ad834cf6b9e371bf73776aa)
(cherry picked from commit 7918496dcf2d6c06a8cd8626c23d2a463343a9df)
(cherry picked from commit ba896a6de0335fca9a5b2ee4ad087c8b640b66c1)
This ensures that cg_kill_items returns the correct value to let the
manager know that a process was killed.
(cherry picked from commit 500cd2e83b8246fbf20d99db898039cfba746223)
(cherry picked from commit 86686e4292fed7ce150156439fbda690bac2ad68)
(cherry picked from commit 64d728921401ac30476d9b0874e621520fb7f5ea)
Linux kernel's bpf-next contains BPF LSM support for s390x. systemd's
test-bpf-lsm currently fails with this kernel.
This is an endianness issue: in the restrict_fs bpf program,
magic_number has type unsigned long (64 bits on s390x), but magic_map
keys are uint32_t (32 bits). Accessing magic_map using 64-bit keys may
work by accident on little-endian systems, but fails hard on big-endian
ones.
Fix by casting magic_number to uint32_t.
(cherry picked from commit 907046282c27ee2ced5e22abb80ed8df2e157baf)
(cherry picked from commit f62e7b470441643d07b23706ac943216a5cdfc97)
(cherry picked from commit 25cb55890ec9a1bd7367e7a84a4df3a3287c7622)
Follow-up for c95df5879eeb2cec8bc8eec2cfa7e741e1d9469f.
Fixes#26196.
(cherry picked from commit 2cb1cabb412850e88eaf26feec663674e2c4f664)
(cherry picked from commit 318b6f60b8f91846331c2a4c65347c75b1203104)
(cherry picked from commit 0f967fba156e74fd5071fee65e318d6332c81dcc)
RFC3442 specifies option 121 (Classless Static Routes) that allow a DHCP
server to push arbitrary routes to a client. It has a Local Subnet
Routes section expliciting the behavior of routes with a null (0.0.0.0)
gateway.
Such routes are to be installed on the interface with a Link scope, to
mark them as directly available on the link without any gateway.
Networkd currently drops those routes, which is against the RFC, as
Linux has proper support for such routes.
Fixes: 7f20627 ("network: dhcp4: ignore gateway in static routes if destination is link-local or in the same network")
(cherry picked from commit 1d84a3c7792a8910b05904937c703307ca19740f)
(cherry picked from commit b0f514ba567a1f6321f6b7f1ded038f8090c70f0)
(cherry picked from commit ee6475d31815fe3e012d48ef7302a5d73e3a8a5d)
"resolvectl status" shows per-link DNS servers separately from global
ones. When querying the global list, it will contain both per-link and
global servers however. Thus, to not show duplicate info we filter all
entries that actually have a non-zero ifindex set (under the assumption
that that's a per-link server).
This doesn't work if people configured 127.0.0.1 as global server
though, as we'll add ifindex 1 to it since
6e32414a66ff8dbcef233981a7066684d903ee9f unconditionally even for global
servers.
Let's address that by excluding entries with ifindex 1 from suppression.
This is safe as resolved ignores loopback ifaces, hence never will have
per-link servers on ifindex 1.
Note that this splits up the "with_ifindex" parameter into a second
parameter "only_global", since they semantically do two different
things. One controls whether we shall expect/parse an ifindex dbus
field. The other controls whether we shall filter all ifindex values set
!= 0. These are effectively always used in conjunction hence making them
the same actually worked. However this is utterly confusing I think,
which as I guess is resulting in the confusion around #25796 (which
removes the whole check)
Replaces: #25796
(cherry picked from commit 889a1b9f4e799b31f1be06db74708aa8beb70829)
(cherry picked from commit b71ade8779002d7feb61a43bc8c2d8325b3d6750)
(cherry picked from commit fa04709a3daacb6e201460be2dd610f6b85778f3)
(cherry picked from commit a5e6c8498ca375bafa865d5e46fa95e9313871ad)
(cherry picked from commit ed26f98f2f0559aee242836e71832a77a7000dbb)
(cherry picked from commit 87307bfdd107fc40440456cfcbf550f4bd679751)
This ensures that udev scripts using `TAG-="..."` and expecting later
udev rules to honor it will work properly. An use case is removing the
`uaccess` tag from a device without overriding the original file and
ensuring that `73-seat-uaccess.rules` won't run the uaccess builtin later.
(cherry picked from commit 310249903986957997b76bc52441cabb5843aad8)
(cherry picked from commit 7d4ea095d5e3e5aa87761c6c0f5f30287596dd75)
(cherry picked from commit ca948c9601714c8de53a87a548dfad05fef37c40)
The text said /dev/tty* as a whole was the VT subsystem and that VT is
not supported in containers.
But that's not accurate as /dev/tty* will match /dev/tty too and that
one device node is special and is not related to VT: it always points to
the current process own controlling tty, regardless what that is.
hence, rewrite /dev/tty* as /dev/tty[0-9]*.
(cherry picked from commit 6ae5c39af1da5b0b6e49278e7a33158d49ec04a5)
(cherry picked from commit f3d620f5d2c26c546d9a5c410c3aa68329b74330)
(cherry picked from commit b4e56b13a98567a113a495f754258529996806b1)
We want to make use of that when formatting file systems, hence let's
pull in these modules explicitly.
(This is necessary because we are an early boot service that might run
before systemd-tmpfiles-dev.service, which creates /dev/loop-control and
/dev/mapper/control.)
Alternatively we could just order ourselves after
systemd-tmpfiles-dev.service, but I think there's value in adding an
explicit minimal ordering here, since we know what we'll need.
Fixes: #25775
(cherry picked from commit ce7dcfd6b00b8099d1793d04bcfa9968ca4a0d96)
(cherry picked from commit 3856b97f8bcbde01b1e2ceb3b008513a2327d64d)
(cherry picked from commit 208153c32bb6b355436fc6a8679cba1cd4d4078d)
Follow-up for 8f1359bf854e9683e4e0b89fd3a537e0d82d4b95
(cherry picked from commit 143a1f1039d992001d2f2f35b2e6ba07f8a52af7)
(cherry picked from commit 67467efd58b0b9814e92dfaa1edc21ebf2c830e7)
(cherry picked from commit 923264e0345fdf2a949ef1eb1b4ccef50457fb20)
