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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
(cherry picked from commit 582843ee37fb2de62321085dd3c2f4bfbdbad12e)
(cherry picked from commit c4e7cf2bd734b480c38b16c227a2b4f1928df270)
(cherry picked from commit dec5e2e7b5ae829b8542810c5d44daed3442cb28)
This ensures that shell string escape operations will not produce output
with invalid UTF-8 from the input by escaping invalid UTF-8 data as if
they were single byte characters.
(cherry picked from commit 00f57157f32f6ed5a68d68986b013c203cd78c37)
(cherry picked from commit e906fd24214f53f1160918a5bb55a1d14368bfd8)
(cherry picked from commit e0a674f7f8ed934eb3b600f09b0ca75a9579293c)
We checked ERRNO_IS_NOT_SUPPORTED on a possible positive non-error code,
which isn't right.
Fix that. Also add caching, since we are about to call this more often.
(cherry picked from commit 90ec8ebe33ec72ed6d9f451de9443d67dd351d72)
(cherry picked from commit 5ee19fdfa054f68e82cedbbff26d60c893ca5ef4)
(cherry picked from commit 8e6234064d3339f3043d2bc42dd8d493d656f08e)
If the default target is masked, `systemctl get-default` prints
Failed to get default target: Operation not possible due to RF-kill
That's a bit too cryptic, so let's make it clear what's actually
happening.
Fixes#26589.
(cherry picked from commit 7c78a19322962bb386f87bcaf37bf650cca1c400)
(cherry picked from commit 144ac494ec8f13e4da2420720c96808046947762)
(cherry picked from commit 30eae23c4a061f1a5cf25dcbd9187560c491b92b)
(cherry picked from commit aff131775b002ddac74b1c65d849dcd52a02c06d)
(cherry picked from commit dc98d58dd8864d537d38cc78617c0a1bf7385ee8)
(cherry picked from commit 7d3af1ff11d17e4cac02668537e6e59e78fe5fc4)
In config_parse_socket_listen(), we have checked the path is absolute,
however we have not in the dbus method.
(cherry picked from commit 4de2b47bdec8bbb7df78678a152f18281b20e7b5)
(cherry picked from commit e093acd062f36de4471948c6d932b931333af4da)
(cherry picked from commit 22d1f01b052e5f938201340a0279f2013bcf8986)
Follow-up for 6d2326e036ceed30f9ccdb0266713c10a44dcf6c.
(cherry picked from commit 1912f790fee9e0182acd77b77496f500094a140d)
(cherry picked from commit a719c2ec2f410f8b979cec04dcdac9af470ee52b)
(cherry picked from commit dd6561ff3e12314d41954b7ea8e3627101931a18)
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 6d2326e036ceed30f9ccdb0266713c10a44dcf6c)
(cherry picked from commit 58c821af607b61738b7b72ad1452e70f648689a6)
(cherry picked from commit 78976199b2e016600c3f7cf8f39747c9ef6c853b)
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 b59052be261523721a86caf4ef820e63f03e26a4)
(cherry picked from commit 2bfb07b22ff1cce4f663740bff202bd65f041916)
(cherry picked from commit 028cee00dd5e37ef94ce11c06d7fdc61dd2a6f47)
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)
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 464ec1dec741e31d7bf08a4b7bb5a64a6adbb81d)
(cherry picked from commit eae11e3f064372ec30efe460381ce807238daa82)
(cherry picked from commit 8af5e945c7d489e7cf4c1dd29612e5452122b754)
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)
This is useful for debugging issues like #26474.
(cherry picked from commit b9fadf2e2cb83d342342341b0edba4f519890634)
(cherry picked from commit ba1cb4156bb7df9d5ce1b35a25425e544f6989de)
(cherry picked from commit 892fe5d2049b1cb25a523c51518fd66a14642974)
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)
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 6aa2c55522d7cac62ecfd5d5687a86a84f158d18)
(cherry picked from commit 01b90e1588e29888c7583bd320b898b59257d737)
(cherry picked from commit 7c9b9c8d93b57f06ad1974adfa1fc0e94ac7b405)
Follow-up for 29a24ab28e9790680348b1ffab653a321fa49a67.
(cherry picked from commit dbfc096095cb741f5345be0dc6508628008c46d7)
(cherry picked from commit a3177cbe546537c873d477138014d054b1cc6376)
(cherry picked from commit 6e8d76f776b02eadfa6e4575f516866786fd3817)
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)
