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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The implementation of MountImageUnit()/systemctl mount-image was
changed to use a /proc/self/fd path as the source, but that causes
the dm-verity files autodiscovery to fail, as it looks for files
in the same directory as the image.
Use the original file path when setting up dm-verity.
That file only exported one function, and it fits nicely within the scope of
"parse helpers". Let's move it there to reduce the file count a bit.
No functional change.
This is a high-level function, and it belongs in libsystemd-shared. This way we
don't end up linking a separate copy into various binaries. It would even end
up in libsystemd, where it is not needed. (Maybe it'd be removed in some
optimization phase, but it's better to not rely on that.)
$ grep -l -r -a 'path is not absolute%s' build/
build/libnss_systemd.so.2
build/pam_systemd_home.so
build/test-dlopen
build/src/basic/libbasic.a.p/path-util.c.o
build/src/basic/libbasic.a
build/src/shared/libsystemd-shared-249.so
build/test-bus-error
build/libnss_mymachines.so.2
build/pam_systemd.so
build/libnss_resolve.so.2
build/libnss_myhostname.so.2
build/libsystemd.so.0.32.0
build/libudev.so.1.7.2
$ grep -l -r -a 'path is not absolute%s' build/
build/src/shared/libsystemd-shared-251.a.p/parse-helpers.c.o
build/src/shared/libsystemd-shared-251.a
build/src/shared/libsystemd-shared-251.so
No functional change.
We would use a relative path, looking for globs like
'lib/systemd/libsystemd-shared-*.so' under the build directory, and never find
anything.
The test was supposed to find library in the current installation. But we
cannot assume that the right library is installed, so the test only printed the
result for manual inspection. Thus nobody noticed when it broke. I think it
broke in c6134d3e2f1d1d17b32b6e06556cd0c5429bc78a, path-util: get rid of prefix_root().
But that commit doesn't compile because of changes in meson, so this is just
a guess.
Before:
/* test_systemd_installation_has_version */
Current installation has systemd >= 0: no
Current installation has systemd >= 231: no
Current installation has systemd >= 249: no
Current installation has systemd >= 999: no
With the fix:
$ build/test-nspawn-util
/* test_systemd_installation_has_version */
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (OK).
Current installation has systemd >= 0: yes
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (OK).
Current installation has systemd >= 231: yes
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (too old).
Found libsystemd shared at "/lib/systemd/libsystemd-shared-251.so.so", version 251 (OK).
Current installation has systemd >= 251: yes
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (too old).
Found libsystemd shared at "/lib/systemd/libsystemd-shared-251.so.so", version 251 (too old).
Found libsystemd shared at "/lib/systemd/libsystemd-shared-250.so.so", version 250 (too old).
Found libsystemd shared at "/usr/lib/systemd/libsystemd-shared-245.so.so", version 245 (too old).
Found libsystemd shared at "/usr/lib/systemd/libsystemd-shared-251.so.so", version 251 (too old).
Found libsystemd shared at "/usr/lib/systemd/libsystemd-shared-250.so.so", version 250 (too old).
Current installation has systemd >= 999: no
$ build/test-nspawn-util /var/lib/machines/rawhide
/* test_systemd_installation_has_version */
/* test_systemd_installation_has_version */
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (OK).
/var/lib/machines/rawhide has systemd >= 0: yes
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (OK).
/var/lib/machines/rawhide has systemd >= 231: yes
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (OK).
/var/lib/machines/rawhide has systemd >= 251: yes
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (too old).
Found libsystemd shared at "/var/lib/machines/rawhide/usr/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (too old).
/var/lib/machines/rawhide has systemd >= 999: no
While at it, NULSTR_FOREACH → FOREACH_STRING.
See a2b0cd3f5ab3f450e74e2085ad20372a05451c74. When -Dshared-lib-tag is used,
libsystemd-shared.so and libsystemd-core.so get a suffix which breaks the
parsing done by systemd_installation_has_version(). We can assume that the
tag will be something like "251-rc1-1.fc37" that is currently used in Fedora.
(Anything that does *not* start with the version would be completely crazy.)
By switching to strverscmp_improved() we simplify the code and fix comparisons
with such versions.
$ build/test-nspawn-util /var/lib/machines/rawhide
...
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251-rc1-1.fc37 (OK).
/var/lib/machines/rawhide has systemd >= 251: yes
...
I noticed this when I started a systemd-nspawn container with Redora rawhide
and got the message "Not running with unified cgroup hierarchy, LSM BPF is not
supported". I thought the message is in error, but it was actually correct:
nspawn was misdetecting that the container does not sport new-enough systemd
to support cgroups-v2.
This function implements a heuristic that is only used by nspawn. It doesn't
belong in basic. I opted for a new file "nspawn-utils.c", because it seems
likely that we'll need some other new utilities like that in the future.
No functional change.
If the time unit changes after adding the repetition value, the
timer may skip the next elapse. This patch reset sub time units
to minimum value when upper unit is changed.
Fixes#22665.
Since c6552ad we now try to collect coverage even in situations where
it's basically impossible (like in test-mount-util where the whole / is
mounted as read-only). As dealing with this is not worth the trouble,
let's ignore the missing coverage errors thrown by gcov in such cases.
Current md_list_get() implementation filters all block devices, started from
"md*". This is ambiguous because list could contain:
- partitions created upon md device (mdXpY)
- external metadata container- specific type of md array.
For partitions there is no issue, because they aren't handle STOP_ARRAY
ioctl sent later. It generates misleading errors only.
Second case is more problematic because containers are not locked in kernel.
They are stopped even if container member array is active. For that reason
reboot or shutdown flow could be blocked because metadata manager cannot be
restarted after switch root on shutdown.
Add filters to remove partitions and containers from md_list. Partitions
can be excluded by DEVTYPE. Containers are determined by MD_LEVEL
property, we are excluding all with "container" value.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
9afd5e7b975e8051c011ff9c07c95e80bd954469 introduced a build-time
taint, introduce a runtime one as well, in preparation for
removing support for unmerged-usr in a future release
We've had this text since the beginning, but in fact the patterns must be
stable in order for people to create local hwdb entries. And we support that
and can't change the match patterns without being very careful. So let's just
drop the text.
Previously, systemd-analyze verify would return 0 even if warnings
were raised during analysis of the specified units or their
dependencies. With 3cc3dc7, verify was changed to return 1 when
warnings were raised.
This commit changes the default mode to _RECURSIVE_ERRORS_INVALID
so that verify returns zero again by default when warnings are
raised.
If we have two or more devices that share the same slot but they are
also multifunction then it is OK to use the slot information even if it
is the same for all of them. Name conflict will be avoided because we
will append function number and form names like, ens1f1, ens1f2...
