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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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)
systemd supports /etc/machine-id to be set to: uninitialized
In this case the expectation is that systemd creates a new
machine ID and replaces the value 'uninitialized' with the
effective machine id. In the scope of kernel-install we
should also enforce the creation of a new machine id in this
condition
(cherry picked from commit 305dd91adfde332e7e5c1b2470edb32774f9a032)
(cherry picked from commit 132f0ec7de303538dcdae02175a807fec97712b8)
Backported for https://bugzilla.redhat.com/show_bug.cgi?id=2148464.
The kernel-install script has code to read the contents of
/etc/machine-id into the MACHINE_ID variable. Depending
on the variable content kernel-install either logs the
value or creates a new machine id via 'systemd-id128 new'.
In that logic there is one issue. If the file /etc/machine-id
exists but is empty, the script tries to call read on an
empty file which return with an exit code != 0. As the
script code also uses 'set -e', kernel-install will exit at
this point which is unexpected.
The condition of an empty /etc/machine-id file exists for
example when building OS images, which should initialize the
system id on first boot but not staticly inside of the image.
afaik an empty /etc/machine-id is also a common approach
to make systemd indicate that it should create a new system
id. Because of this, the commit makes sure the reading of
/etc/machine-id does not fail in any case such that the
handling of the MACHINE_ID variable takes place.
(cherry picked from commit 883e7cbfc0dba6c81338e7924419b5cbb0cba0b2)
(cherry picked from commit d34ea410f4bac2bbdf8c9a8ba5b27350b80360c4)
Backported for https://bugzilla.redhat.com/show_bug.cgi?id=2148464.
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)
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)
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)
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)
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)
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)
I expected this to work, but our tests did not cover this
explicitly.
(cherry picked from commit 8eb491f4993c6080e9724c0359a87c64c460605e)
(cherry picked from commit 7c0ac515c8094fd62c100477fa293aa31f97e2c4)
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)
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)
Previously, we reported:
nx.example.org: resolve call failed: 'nx.example.org' not found
But the call did succeed, and in fact all communication with the upstream
servers was successful, and we got an authoritative negative answer.
So instead of saying that the call fail, just say that the host doesn't exist:
nx.example.org: Name 'nx.example.org' not found
I wanted to keep the prefix of "<name>: ", to keep the output uniform. But
it'd look a bit strange to say "<name>: <name> not found", so I added "Name "
to make the output more readable. (Another option would be to not display
the error string received from resolved, but that seems risky: even if right
now resolved uses just one message format, it could start doing something else
in the future, so it's better to display the error as received.)
Fixes#26233.
(cherry picked from commit bbb86efa7c668fa79331aa9a7f0567d89a3af50f)
(cherry picked from commit 7c9dcd50f0c31fc39be7df946bd2f009a674049e)
This result is identical after cpp is done, so we don't save anything
by not having the usual macros. And with the usual macros it's easier to
grep and code-crossreferencing works better.
(cherry picked from commit 03e80572a71c65833ccca7b9ef06c5d86322e2ed)
(cherry picked from commit c538abc8bdad7ef7135f36df7488c5b0b43e8be7)
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)
[2/3] Compiling C object systemd-repart.p/src_partition_repart.c.o
../src/partition/repart.c: In function ‘context_open_copy_block_paths’:
../src/partition/repart.c:5194:41: warning: ‘devno’ may be used uninitialized [-Wmaybe-uninitialized]
5194 | source_fd = r = device_open_from_devnum(S_IFBLK, devno, O_RDONLY|O_CLOEXEC|O_NONBLOCK, &opened);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/partition/repart.c:5188:31: note: ‘devno’ was declared here
5188 | dev_t devno;
| ^~~~~
This is with gcc-13.0.1-0.2.fc38.x86_64, -O2. I'm pretty sure the code
is correct. I also tried adding some asserts where errno is used for the return
value, but that didn't help. I think resolve_copy_blocks_auto() is just too long
for gcc to understand.
(cherry picked from commit 03f5e501b6b58cb05a275403af4a36694ff0c205)
(cherry picked from commit 53ca414a451aa090ae4d2f5c8c181b03c7f2dd88)
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)
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)
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)
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)
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)
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)
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)
Currently rename_netif() will not attempt to rename a device if it is
already up, because the kernel will return -EBUSY unless live renaming
is allowed on the device. This restriction will be removed in a future
kernel version [1].
To cover both cases, always attempt to rename the interface and return 0
if we get -EBUSY.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=bd039b5ea2a9
(cherry picked from commit 53584e7b61373c26635b906eb64e98fbd3fd3ba4)
(cherry picked from commit c6722b697530902968eb87fd5ac398184980ea3f)
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)
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)
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)
Fixes a bug introduced by db50d326a46beca3cc24b6354b6e1b3591902d45.
Fixes RHBZ#2167468 (https://bugzilla.redhat.com/show_bug.cgi?id=2167468).
(cherry picked from commit 1c3762937e9184c9abbc8d5541b4228841ccc24f)
(cherry picked from commit 5ce6c73f2db1b2bf9064f8b4344645c8ffdd84bd)
Fixes a bug introduced by db50d326a46beca3cc24b6354b6e1b3591902d45.
(cherry picked from commit a3b993ca3fb6fc0b837745c1ae82aca684951842)
(cherry picked from commit 7503626febb6fb9319ed6de4ef67011e8cd50572)
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)
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)
Follow-up for c95df5879eeb2cec8bc8eec2cfa7e741e1d9469f.
Fixes#26196.
(cherry picked from commit 2cb1cabb412850e88eaf26feec663674e2c4f664)
(cherry picked from commit 318b6f60b8f91846331c2a4c65347c75b1203104)
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)
"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)
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)
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)
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)
