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 the boot ID cannot be obtained, let's first fallback to the machine
ID, and if still cannot, then let's use 0.
Otherwise, no timer event source cannot be triggered.
Fixes#26549.
(cherry picked from commit 6d2326e036)
(cherry picked from commit 58c821af60)
(cherry picked from commit 78976199b2)
Only service and scope units have RuntimeMaxUSec bus property.
To suppress the "Until:" field for other unit types, the entry must be
initialized with USEC_INFINITY.
Fixes#26473.
(cherry picked from commit b59052be26)
(cherry picked from commit 2bfb07b22f)
(cherry picked from commit 028cee00dd)
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 c4708f1323.
Maybe an earlier version of the patch did something different.
(cherry picked from commit 9c7188547c)
(cherry picked from commit d9abd8babe)
(cherry picked from commit 2ca2390b11)
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 1eca770933)
(cherry picked from commit 44c2ff5b1e)
(cherry picked from commit 4f4344e3a5)
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 164297cd9a)
(cherry picked from commit aac692160e)
(cherry picked from commit e72f1676af)
This is useful for debugging issues like #26474.
(cherry picked from commit b9fadf2e2c)
(cherry picked from commit ba1cb4156b)
(cherry picked from commit 892fe5d204)
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 db4691961c)
(cherry picked from commit c4cdbb978f)
(cherry picked from commit e9889190be)
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 f92428eae5)
(cherry picked from commit cd5de2811a)
(cherry picked from commit ac3d8922df)
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 3dd6336ad0)
(cherry picked from commit a88e35bf95)
(cherry picked from commit 58cbb7a89b)
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 305dd91adf)
(cherry picked from commit 132f0ec7de)
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 883e7cbfc0)
(cherry picked from commit d34ea410f4)
Backported for https://bugzilla.redhat.com/show_bug.cgi?id=2148464.
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 0da4cc97b4)
(cherry picked from commit ef96e60f18)
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 32d6707dd1)
(cherry picked from commit c973e2295c)
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 164070e497)
(cherry picked from commit 0dc9f7335d)
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 a99bd455b5)
(cherry picked from commit 9bb72a4e96)
This effectively reverts commit ff86c92e30,
and re-apply 49f3ee7e74.
The change was dropped due to the process name was not correctly logged,
but the issue was fixed by dd15e4cb57.
Let's set the child process name again.
(cherry picked from commit e955a7f460)
(cherry picked from commit 62055cfd4b)
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 bbb86efa7c)
(cherry picked from commit 7c9dcd50f0)
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 03e80572a7)
(cherry picked from commit c538abc8bd)
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 dd15e4cb57)
(cherry picked from commit ce4726468d)
[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 03f5e501b6)
(cherry picked from commit 53ca414a45)
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 19cfda9fc3)
(cherry picked from commit 015b0ca928)
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 49bb7fe5f8)
(cherry picked from commit 8ad3d68acd)
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 181eea677d)
(cherry picked from commit 817b8441c4)
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 b52031dbbc)
(cherry picked from commit 7aeb2a8d4e)
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 0398c084ef)
(cherry picked from commit ab877f7072)
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 2642d22adc)
(cherry picked from commit 3a49291f4b)
Add a test that verifies a deleted alternative name is restored on error
in rtnl_set_link_name().
(cherry picked from commit b338a8bb40)
(cherry picked from commit 7299341bd1)
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 53584e7b61)
(cherry picked from commit c6722b6975)
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 4d600667f8)
(cherry picked from commit 42d8817bd6)
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 080afbb57c)
(cherry picked from commit 3dc5b19f10)
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 d0b31efc1a)
(cherry picked from commit 7918496dcf)
