"path" sounds like a fully qualified complete string referencing some
terminal object. But here it's not like that, the field just stores the
directory the object we actually care about is placed in. Hence let's
change this field to be named "directory", to be less confusing for
readers.
This PR implements what is proposed in
https://github.com/systemd/systemd/issues/37992.
Having a global config file that supports the same cmdline options for
sysext/confext allows the user to customize the behavior of
systemd-sysext.service unit too, without the need of hacking the service
manually.
The global config will live in
`CONF_PATHS_STRV()/systemd/{sysext/confext}.conf` and it will be
overridden by cmdline, so it is possible to customize a run if
`systemd-sysext` is executed manually.
For now support `--mutable=` (`Mutable`) and `--image-policy=`
(`ImagePolicy`).
Enhance CPU time logging to include wall clock duration alongside
CPU consumption. When a unit transitions to inactive/failed state,
the log message now shows both CPU time consumed and the total wall
clock time since activation.
Changes:
- Calculate wall clock duration using active_enter_timestamp
- Update log format: "Consumed Xs CPU time over Ys wall clock time"
- Fallback to original format if no activation timestamp available
- Use monotonic clock for accurate duration calculation
This addresses issue #35738 by providing administrators better context
about service performance and resource efficiency.
Example output:
- With wall clock: "service: Consumed 30s CPU time over 5min wall clock time"
- Without timestamp: "service: Consumed 30s CPU time"
Container managers may want to bind mount the root filesystem
somewhere within the container. Security-wise, this is very much not
recommended, but it may be something application containers may want
to do nonetheless.
Ref: https://github.com/flatpak/flatpak/pull/6125#issuecomment-2759378603
We only support a subset of filesystems, and no RAID, for DDIs. blkid spends a lot
of time trying to probe for the filesystem type, so cut it short by using
the filtering options to restrict it to the filesystems we support, and to
exclude raid probing.
The code was of two minds about error_id: it was used directly in
pam_syslog_errno(), but in the next line checked with streq_ptr().
sd_varlink_callbo() may return negative and then it does not set the output
params, or it returns the error in ret_error_id. We cannot assume that error_id
is non-null. Also fix a select-and-paste mistake in one place.
I'm seeing this in the initrd (with the dev_ksmg_record line added to clarify
where the error is coming from):
[ 6.114232] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.2
[ 6.116842] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.2".
[ 6.134115] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.2".
[ 6.139427] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.144327] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.149442] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.155091] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.160118] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.164814] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.169201] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.173990] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.183104] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.187746] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.192825] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.197733] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.203015] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.3
[ 6.207184] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.3".
[ 6.211943] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.3".
[ 6.216703] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.221944] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.226803] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.231238] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.236078] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.241845] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.247976] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.252545] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.256146] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.260651] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.265151] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.269755] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.276206] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.4
[ 6.280034] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.4".
[ 6.284603] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.4".
[ 6.288710] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.293312] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.297763] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.302438] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.306948] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.310797] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.315097] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.319033] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.323593] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.328834] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.333057] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.337644] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.341152] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.5
[ 6.345436] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.5".
[ 6.349824] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.5".
[ 6.354306] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.358131] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.366568] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.371139] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.375207] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.378681] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.382820] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.387143] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.392192] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.397109] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.400991] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.405992] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.410889] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.6
[ 6.414730] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.6".
[ 6.418266] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.6".
[ 6.422575] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.429942] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.433780] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.438509] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.442293] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.447236] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.453336] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.458031] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.461948] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.465883] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.470072] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.476196] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.481182] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:02.7
[ 6.484938] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:02.7".
[ 6.491322] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:02.7".
[ 6.497289] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.501935] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.505217] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.509819] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.516078] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.520942] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.525178] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.528505] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.534669] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.539353] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.543035] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.547441] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.553211] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.0
[ 6.557452] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/class/pci/0000:00:03.0".
[ 6.562468] systemd-journald[251]: sd-device: Failed to chase symlinks in "/sys/firmware/pci/0000:00:03.0".
[ 6.566955] systemd-journald[251]: dev_kmsg_record: kernel_device=+pci:0000:00:03.1
[ 6.570846] systemd-journald[251]: Too many messages being logged to kmsg, ignoring
The error message was misleading, since it sounds like there's an issue with
symlinks, but the device simply doesn't exist. But I think we should suppress
the message altogether. journald spewing messages like this fills up the logs
for no benefit. The sd_device_new* functions can legitimately be used for
"invalid" devices, e.g. to check if they even exist. We have no idea for what
purpose the caller is creating the device object, so let's not log this at all.
The caller can log if appropriate.
For file:// there's no http error code 404, but there's
CURLE_FILE_COULDNT_READ_FILE hence call ->on_not_found() in that case
too.
Follow-up for: c456862f87
When running in the initrd --root= is automatically set to /sysroot or /sysusr
but then using CopyBlocks fails due to a security measure:
root@particle-caba-1e47:~# systemd-repart --dry-run=no /dev/vda
No machine ID set, using randomized partition UUIDs.
Automatic discovery of backing block devices not permitted in --root= mode, refusing.
Follow-up for 5c08da586f
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able to have
it in /nix/store too like the other util-linux tools).
Given that `unmerged-usr` support was dropped in 255 I think this is a
safe change?
path_is_root_at() is supposed to detect if the inode referenced by the
specified fd is the "root inode". For that it checks if the inode and
its parent are the same inode and the same mount. Traditionally this
check was correct. But these days we actually have detached mounts (i.e.
those returned by fsmount() and related calls), whose root inode also
behaves like that.
Our uses for path_is_root_at() use the function to detect if an absolute
path would be identical to a relative path based on the specified fd
(sepifically: chaseat()), which goes really wrong if used on a detached
mount.
hence, let's adjust the function a bit, and let's go by path to "/" to
check if the referenced inode is the actual root inode in our chroot.
Commit d7bea6b6 ("nspawn: introduce an option for specifying network
namespace path") already did most of the work here enabling a command
line option for specifying the namespace path for a given container.
Someone even took care of the merging code in merge_settings as though
this already worked. All that's then needed is to add a line to the
nspawn-gperf.gperf file to actually enable being able to specify
NamespacePath from nspawn files as well.
This greatly simplifies how we configure nspawn containers by being able
to give all the options we need in .nspawn files instead of needing to
also use command line parameters.
Closes: #27188
These images are not using a passphrase, they are using keys
or at most TPM-based sealing (not yet implemented, for contexts).
Do not use the interactive helper, as it will block and ask the
user for a password if it fails to find the signing cert, which
is not useful for this tool.
Fixes https://github.com/systemd/systemd/issues/33179
Registering a process as a machine means a caller can get machined to
send sigterm to it, and more. If an unpriv user is registering, ensure
the registered process has the same uid.
Follow-up for adaff8eb35
* 7d9cf5c9347 Update systemd to version 257.9 / rev 456 via SR 1303345
* 439d743e5d6 Update systemd to version 257.7 / rev 455 via SR 1297651
* 4f72c6a6279 Update systemd to version 257.7 / rev 454 via SR 1296831
* 3b0afa5c6d1 Update systemd to version 257.7 / rev 453 via SR 1294979
* d0eccd20f5a Update systemd to version 257.7 / rev 452 via SR 1292221
* f9d183f8c57 Update systemd to version 257.7 / rev 451 via SR 1291008
* cbd6908247d Update systemd to version 257.7 / rev 450 via SR 1289968
* 6e5c00f9f92 Update systemd to version 257.6 / rev 449 via SR 1286997
Signed-off-by: val4oss <github.widget541@passmail.net>
Registering a process as a machine means a caller can get machined
to send sigterm to it, and more. If an unpriv user is registering,
ensure the registered process is actually owned by the user.
Follow-up for adaff8eb35
Coverity gets confused because the names were swapped. The parameters
are all passed in the right position, so there's no functional issue,
but the naming is confusing and trips static analyzers, so fix it.
CID#1621624
Follow-up for 8a9ab3dbbc
If the test VM reboots and the test re-runs, creating the images
fails as they already exist:
[ 218.227766] TEST-50-DISSECT.sh[889]: + mksquashfs testkit/ testkit.raw
[ 218.238754] TEST-50-DISSECT.sh[2964]: FATAL ERROR: Could not read $HOME, use -recovery-path or -no-recovery options
[ 218.239284] TEST-50-DISSECT.sh[2964]: Found a valid exportable SQUASHFS superblock on testkit.raw.
[ 218.239554] TEST-50-DISSECT.sh[2964]: Compression used gzip
[ 218.240176] TEST-50-DISSECT.sh[2964]: Inodes are compressed
[ 218.240459] TEST-50-DISSECT.sh[2964]: Data is compressed
[ 218.241072] TEST-50-DISSECT.sh[2964]: Fragments are compressed
[ 218.241526] TEST-50-DISSECT.sh[2964]: Xattrs are compressed
[ 218.241953] TEST-50-DISSECT.sh[2964]: Fragments are present in the filesystem
[ 218.242411] TEST-50-DISSECT.sh[2964]: Always-use-fragments option is not specified
[ 218.242843] TEST-50-DISSECT.sh[2964]: Duplicates are removed
[ 218.243560] TEST-50-DISSECT.sh[2964]: Xattrs are stored
[ 218.243889] TEST-50-DISSECT.sh[2964]: Filesystem size 0.38 Kbytes (0.00 Mbytes)
[ 218.244563] TEST-50-DISSECT.sh[2964]: Block size 131072
[ 218.245051] TEST-50-DISSECT.sh[2964]: Number of fragments 1
[ 218.245512] TEST-50-DISSECT.sh[2964]: Number of inodes 6
[ 218.245851] TEST-50-DISSECT.sh[2964]: Number of ids 1
[ 218.246393] TEST-50-DISSECT.sh[2964]: Parallel mksquashfs: Using 2 processors
[ 218.246820] TEST-50-DISSECT.sh[2964]: Scanning existing filesystem...
[ 218.247286] TEST-50-DISSECT.sh[2964]: Read existing filesystem, 5 inodes scanned
[ 218.252974] TEST-50-DISSECT.sh[2964]: Appending to existing 4.0 filesystem on testkit.raw, block size 131072
[ 218.253593] TEST-50-DISSECT.sh[2964]: All -b, -noI, -noD, -noF, -noX, -noId, -no-duplicates, -no-fragments,
[ 218.253848] TEST-50-DISSECT.sh[2964]: -always-use-fragments, -exportable and -comp options ignored
[ 218.257196] TEST-50-DISSECT.sh[2964]: If appending is not wanted, please re-run with -noappend specified!
https://github.com/systemd/systemd/actions/runs/17674609143/job/50233691148?pr=38867
There is a botched arm64 linker transition going on, where a new feature
is enabled (GCS) and the linker fails the build unless all object files
being linked are built with the new specific feature. This was enabled
in the toolchain (GCC 15) _before_ all libraries were rebuilt, including
glibc, so everything fails. The toolchain maintainers declined to fix it
and instead say that this is a useless warning to have, and to just
disable it and ignore it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110461
> systemd fails to build from source on arm64 if built with GCC-15, currently in
> experimental.
>
> GCC-15 includes support for an arm64 security feature called Guarded Control
> Stack (GCS). To help with GCS adoption, the linker warns about shared libraries
> built without GCS. For example:
>
> /usr/lib/gcc/aarch64-linux-gnu/15/../../../aarch64-linux-gnu/libncursesw.so.6:
> warning: GCS is required by -z gcs, but this shared library lacks the necessary property note.
> The dynamic loader might not enable GCS or refuse to load the program unless
> all the shared library dependencies have the GCS marking.
>
> The warning is harmless, and can be ignored. However, systemd is built with
> --fatal-warnings, and for this reason will fail to build on arm64 once GCC-15
> becomes the default compiler in Debian.
[585/3230] Linking target src/core/libsystemd-core-258.so
FAILED: src/core/libsystemd-core-258.so
gcc -o src/core/libsystemd-core-258.so -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,-soname,libsystemd-core-258.so -Wl,--whole-archive -Wl,--start-group src/core/libsystemd-core-258.a -Wl,--no-whole-archive -fstack-protector -Wl,-z,relro -specs=/usr/share/debhelper/dh_package_notes/debian-package-notes.specs -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/work/src=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -O0 -g -Og -Wdate-time '-Wl,-rpath,$ORIGIN/../shared' src/shared/libsystemd-shared-258.so -shared -Wl,--version-script=/work/src/src/shared/libshared.sym /usr/lib/aarch64-linux-gnu/libacl.so /usr/lib/aarch64-linux-gnu/libaudit.so /usr/lib/aarch64-linux-gnu/libblkid.so -ldl -lm /usr/lib/aarch64-linux-gnu/libmount.so -lrt /usr/lib/aarch64-linux-gnu/libseccomp.so /usr/lib/aarch64-linux-gnu/libselinux.so -Wl,--end-group -pthread -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--gc-sections -Wl,--warn-common
src/shared/libsystemd-shared-258.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libacl.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libaudit.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libblkid.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libm.so.6: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libmvec.so.1: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libmount.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libseccomp.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libselinux.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libc.so.6: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/ld-linux-aarch64.so.1: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
collect2: error: ld returned 1 exit status
The default is already to propagate the env vars, so this
was unnecessary and actually creates problem as it removes
custom PATHs
This reverts commit 994af53395.
After the update to systemd 257.7 in Fedora, there are reports that we fail to
create a symlink:
systemd-gpt-auto-generator[585]: Failed to create symlink /run/systemd/generator/local-fs.target.wants/systemd-fsck-root.service: File exists
(sd-exec-[574]: /usr/lib/systemd/system-generators/systemd-gpt-auto-generator failed with exit status 1.
I guess that some other generator created the symlink. We silently ignore
EEXIST in similar codepaths, so add that in one more place. (The target of the
symlink doesn't really matter. The name of the link matters. So something like
symlink_idempotent would not be better. For example, a different generator
might use a slightly different target path, and symlink_idempotent would be too
strict.)
Because it returns the result of the final sd_path_lookup() call rather than the return value of RET_GATHER,
it appears that it may return success even if an error occurs during processing.
With this patch, errors encountered during the loop will be properly tallied and returned, and failures will not be silently ignored.
Signed-off-by: anthisfan <gtpgx305@gmail.com>
