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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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")
The usual story:
$ diff -u <(pahole build/systemd-sysusers.0) <(pahole build/systemd-sysusers)
/* size: 80, cachelines: 2, members: 15 */
- /* sum members: 68, holes: 1, sum holes: 4 */
- /* sum bitfield members: 5 bits (0 bytes) */
- /* padding: 7 */
- /* bit_padding: 3 bits */
+ /* sum members: 73, holes: 1, sum holes: 4 */
+ /* padding: 3 */
/* last cacheline: 16 bytes */
Effectively, because of padding, we were not saving anything. We're not putting
struct Item in arrays, but when allocating on the heap, we're going to round up to
normal alignment too.
The code becomes shorter (and quicker):
$ size build/systemd-sysusers{,.0}
text data bss dec hex filename
79967 2040 264 82271 1415f build/systemd-sysusers.0
79726 2040 264 82030 1406e build/systemd-sysusers
(In case you're wondering, I wrote this long commit message for a very simple
change on purpose: I want to deflate the bitfield cargo cult a bit.)
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.
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
We might be running in a chroot as a uid that doesn't exist in /etc/passwd.
Let's make sure we don't fail in this scenario.
We pass $HOME when resetting the env so that we can find a home directory
and skip tests that depend on user name/group.
It's still useful to test the EFI handover logic in systemd-boot.
We use a mkosi.prepare script to install a newer python and update
the system to use it.
When unprivileged mkosi becomes available, builds will be executed
as an unprivileged user, so we won't be able to modify the rootfs
anymore. Let's update the build script to account for this.
When using --private-users, we have to create bind mount points as
the user that will become root in the user namespace, so let's take
that into account.
Before this commit, if virtual console keymap is unchanged, localed just
returns without modifying anything. However, the X11 part may need updating.
So we should check for both and ensure they are unmodified.
Replaces #26190.
This also makes x11_convert_to_vconsole() changed in the same way.
Then, their callers update Context if necessary.
No functional change, just preparation for later commits.
Also, rename get_battery_identifier() to siphash24_compress_device_sysattr().
This also makes any errors in sd_id128_get_machine() or id128_get_product()
ignored. For the machine ID, the failure should not be significant unless
the file stored in the discharge level is reused by another system, which
is quite unusual. For the product ID, if the firmware provides useless
ID (all zero or all 0xFF), then loading/storing the discharge rate
becomes completely broken, that should be avoided.
Note, now sysattrs are used instead of properties in uevent files, but
both provide the same information, hence no functionality should be
changed.
Before v252, HibernateDelaySec= specifies the maximum timespan that the
system in suspend state, and the system hibernate after the timespan.
However, after 96d662fa4c8cab24da57523c5e49e6ef3967fc13, the setting is
repurposed as the default interval to measure battery charge level and
estimate the battery discharging late. And if the system has enough
battery capacity, then the system will stay in suspend state and not
hibernate even if the time passed. See issue #25269.
To keep the backward compatibility, let's introduce another setting
SuspendEstimationSec= for controlling the interval to measure
battery charge level, and make HibernateDelaySec= work as of v251.
This also drops implementation details from the man page.
Fixes#25269.
