#3021 Issue closed: systemd private library libsystemd-shared-252.so not found by 'ldd'¶
Labels: enhancement, support / question,
fixed / solved / done, minor bug
LiamFry opened issue at 2023-06-27 07:33:¶
Backup (rear -v mkbackup) reports that a necessary file is missing. I
don't understand ...
- ReaR version: Relax-and-Recover 2.7 / Git
- OS version: Debian GNU/Linux 12 (bookworm)
- ReaR configuration files: (attached)
- System architecture: x86_64
- Storage layout: (attached)
- Description of the issue:
I am not sure if this is arearissue yet I cannot find any useful information elsewhere. (I've tried!) During backup, I get the following message ...
Testing that the recovery system in /var/tmp/rear.PvzABq2iZtXbVTm/rootfs contains a usable system
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-252.so requires additional libraries
libsystemd-shared-252.so => not found
ReaR recovery system in '/var/tmp/rear.PvzABq2iZtXbVTm/rootfs' needs additional libraries, check /var/log/rear/rear-clara.log for details
dpkg --get-selections | grep libsystemd-shared shows that it's
installed.
dpkg -L libsystemd-shared gives me the following ...
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/systemd
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-252.so
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-252.so
/usr/share
/usr/share/doc
/usr/share/doc/libsystemd-shared
/usr/share/doc/libsystemd-shared/NEWS.Debian.gz
/usr/share/doc/libsystemd-shared/changelog.Debian.gz
/usr/share/doc/libsystemd-shared/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libsystemd-shared
All that said, a quick find / -name libsystemd-shared-252.so -ls
reports this:
22458549 3252 -rw-r--r-- 1 root root 3327624 Feb 28 06:15 /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-252.so
local.conf.txt
storage-layout.txt
jsmeix commented at 2023-06-27 09:06:¶
I am not a Debian user
so I cannot reproduce Debian specific issues.
In general when things are missing in the ReaR recovery system
you could manually add what is needed via something like
LIBS+=( /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-252.so )
or
LIBS+=( /usr/lib/x86_64-linux-gnu/systemd/*.so* )
in your etc/rear/local.conf file.
See the descriptions about LIBS and COPY_AS_IS
in usr/share/rear/conf/default.conf
pcahyna commented at 2023-06-27 09:14:¶
I see a similar message on Fedora 37:
Testing that the recovery system in /tmp/rear.OBGH5kwM9RvJv5S/rootfs contains a usable system
There are binaries or libraries in the ReaR recovery system that need additional libraries
/usr/lib/systemd/libsystemd-core-251.14-2.fc37.so requires additional libraries
libsystemd-shared-251.14-2.fc37.so => not found
Weird.
LiamFry commented at 2023-06-27 10:28:¶
A quick run of
ldd /usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-252.so did
report that libsystemd-shared-252.so was missing. This is damned
odd.
I took my question to the Debian
forums. I'll post
here what I discover.
pcahyna commented at 2023-06-27 10:54:¶
Similar on Fedora 37:
# ldd /usr/lib/systemd/libsystemd-core-251.14-2.fc37.so
linux-vdso.so.1 (0x00007ffefb5d6000)
libsystemd-shared-251.14-2.fc37.so => not found
libsystemd-shared-251.14-2.fc37.so is actually in /usr/lib/systemd .
jsmeix commented at 2023-06-27 10:56:¶
I guess that the RequiredSharedObjects function in ReaR
does not get called for libsystemd-core-252.so
so libsystemd-shared-252.so is not automatically
included into the ReaR recovery system.
RequiredSharedObjects is called in
build/GNU/Linux/390_copy_binaries_libraries.sh
for all existing programs in PROGS and REQUIRED_PROGS
and for all libraries in LIBS via
local all_libs=( "${LIBS[@]}" $( RequiredSharedObjects "${all_binaries[@]}" "${LIBS[@]}" ) )
and RequiredSharedObjects is called in
build/GNU/Linux/100_copy_as_is.sh
for all executable files in COPY_AS_IS via
for required_library in $( RequiredSharedObjects "${copy_as_is_executables[@]}" ) ; do
So when libsystemd-core-252.so is not specified in LIBS
but gets included into the recovery system via COPY_AS_IS
and when libsystemd-core-252.so is not an executable file
then RequiredSharedObjects is not called for libsystemd-core-252.so
so libsystemd-shared-252.so gets not automatically included
and when libsystemd-shared-252.so is not explicitly
specified to be included into the recovery system
then libsystemd-shared-252.so is missing in the recovery system.
jsmeix commented at 2023-06-27 10:58:¶
@pcahyna
Ah!
It seems the library configuration on the original system
(i.e. things like ldconfig and so on)
could be incomplete when ldd does not find it.
jsmeix commented at 2023-06-27 11:06:¶
FYI:
On my current openSUSE Leap 15.4 system
I have systemd-249.16 which contains only
/usr/lib/systemd/libsystemd-shared-249.so
and I noticed no issues with that in ReaR.
After "rear -D mkrescue" I get:
# find /var/tmp/rear.Dw2DUk0fyAfXiN6/rootfs | grep libsystemd
/var/tmp/rear.Dw2DUk0fyAfXiN6/rootfs/usr/lib64/libsystemd.so.0
/var/tmp/rear.Dw2DUk0fyAfXiN6/rootfs/usr/lib64/libsystemd.so.0.32.0
/var/tmp/rear.Dw2DUk0fyAfXiN6/rootfs/usr/lib/systemd/libsystemd-shared-249.so
and my var/log/rear/rear-HOSTNAME.log contains
+ source /root/rear.github.master/usr/share/rear/build/GNU/Linux/100_copy_as_is.sh
...
++ Log 'Adding required libraries of executables in all the copied files to LIBS'
...
2023-06-27 13:23:44.707937689 Adding required library '/usr/lib/systemd/libsystemd-shared-249.so' to LIBS
...
2023-06-27 13:23:45.113024540 Adding required library '/usr/lib64/libsystemd.so.0' to LIBS
.
.
.
+ source /root/rear.github.master/usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh
...
2023-06-27 13:23:53.056375594 Libraries being copied: ... /usr/lib/systemd/libsystemd-shared-249.so ... /usr/lib64/libsystemd.so.0 ...
As far as I see in particular in
usr/share/rear/prep/GNU/Linux/280_include_systemd.sh
and in usr/share/rear/conf/GNU/Linux.conf
it seems that
libsystemd-shared-249.so and libsystemd.so.0
are not specified in LIBS
but get included into the recovery system
via executables in COPY_AS_IS or
via programs in PROGS and REQUIRED_PROGS
which should normally be the preferred way
according to my reasoning in
https://github.com/rear/rear/issues/2743
LiamFry commented at 2023-06-28 08:53:¶
I found this post that offered some "solutions." Even though the question was asked for Ubuntu, I found it helpful for Debian.
TL;DR
One-off solution:
sudo bash -c "LD_PRELOAD=/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-252.so" rear -v mkbackup
(untested)
... OR ...
create an file in /etc/ld.so.conf.d
(This is the method I chose.)
I created /etc/ld.so.conf.d/libsystemd-core.conf
... into which I put /usr/lib/x86_64-linux-gnu/systemd
I then ran sudo ldconfig
A run of ldd /usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-252.so
now resolves libsystemd-shared-252.so
I rebooted for good measure and ran a straight rear -v mkbackup -- it
ran flawlessly.
I suppose why libsystemd-core-252.so has this issue is a question for
the distro and subsystem teams.
ekool commented at 2023-08-08 03:49:¶
I just want to add that the above post from LiamFry fixed it for me as well.
sid-the-sloth commented at 2023-08-22 19:31:¶
sudo ldconf
This solution from @LiamFry worked -- but on Debian should do
sudo ldconfig instead.
LiamFry commented at 2023-09-12 06:49:¶
sudo ldconf
This solution from @LiamFry worked -- but on Debian should do
sudo ldconfiginstead.
Thanks for the correction! I updated my "potential solution," above.
zDEFz commented at 2023-10-05 18:22:¶
TLDR;
Had to edit /usr/sbin/rear and add
export LD_PRELOAD=/usr/lib64/systemd/libsystemd-shared-253.10-1.fc38.so
as other solutions did NOT work.
This is a confusing thing.
Tried ... for Fedora 38:
echo "/usr/lib/systemd" | sudo tee -a /etc/ld.so.conf.d/libsystemd-core.conf
sudo ldconfig
Then reboot.
Issue still perists
http://ix.io/4IfE
sudo dnf install systemd-libs-253.2-1.fc38.x86_64
ldd /usr/lib64/systemd/libsystemd-core-253.2-1.fc38.so
linux-vdso.so.1 (0x00007fff0f133000)
libsystemd-shared-253.2-1.fc38.so => not found
libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007fcde1524000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007fcde1512000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007fcde14e3000)
libkmod.so.2 => /lib64/libkmod.so.2 (0x00007fcde14c7000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fcde149a000)
libmount.so.1 => /lib64/libmount.so.1 (0x00007fcde1452000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcde142e000)
libc.so.6 => /lib64/libc.so.6 (0x00007fcde1022000)
libeconf.so.0 => /lib64/libeconf.so.0 (0x00007fcde1421000)
libm.so.6 => /lib64/libm.so.6 (0x00007fcde0f41000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007fcde1418000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fcde0e85000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fcde0e52000)
libz.so.1 => /lib64/libz.so.1 (0x00007fcde0e38000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fcde0a00000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fcde0966000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcde1573000)
libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fcde092e000)
dnf provides libsystemd-shared-253.2-1.fc38.so resolves to systemd-253.2-1.fc38.x86_64 but ldd /usr/lib/systemd/libsystemd-core-253.2-1.fc38.so
export LD_LIBRARY_PATH=/usr/lib/systemd
export LD_LIBRARY_PATH=/usr/lib64/systemd
still same issue.
ufreier commented at 2023-11-15 19:15:¶
Yes, the solution from @LiamFry works in the sense of building a rescue system without errors. BUT ... has anyone successfully booted the system with another device than the original? I have 2 identical servers (one as a cold stand-by) each only with one nvme-ssd and I'm not able to boot 'the other one' with the rescue system (simulating a ssd crash and its replacement). Same env like LiamFry (Debian 12, ReaR 2.7) and same settings for rescue medium like in its local.conf. I tried Debian installations with Legacy and UEFI boot, OUTPUT=USB and OUTPUT=RAWDISK - each try to boot the other one results in hanging after 'Booting rescue system' (UEFI) resp. after 'Probing EDD (edd=off ..) ok'. (Legacy) with no errors but only power reset helps. However, the server where the rescue medium was created boots both (USB and dd'ed RAWDISK). So I suspect there is something on the original device that is needed for booting the rescue medium, that would be worse in case of a real crash. I only have this problem in Debian 12, f.i. in Ubuntu 22.04 ReaR works like expected but I don't want to switch ...
jsmeix commented at 2023-11-16 07:12:¶
@ufreier
only as a side note FYI regarding
hanging after 'Probing EDD (edd=off ..) ok'
see
https://github.com/rear/rear/issues/2955#issuecomment-1465642166
Check your ReaR recovery system kernel command line arguments
with your Debian 12 versus with your Ubuntu 22.04
and look for "console=..." settings.
E.g. for BIOS you can get the
ReaR recovery system kernel command line arguments
by selecting in the ReaR recovery system boot menue
the topmost entry of the form "Recover HOSTNAME" and then
pressing the [Tab] key which shows the kernel command line.
pcahyna commented at 2023-11-16 17:43:¶
@ufreier I suspect that the issue you are encountering is unrelated to the warning message about libsystemd-shared-252.so not found. Can you please open a separate report?
ufreier commented at 2023-11-20 15:25:¶
@jsmeix : thanks a lot, USE_SERIAL_CONSOLE='no' was the solution!
jsmeix commented at 2023-11-21 07:57:¶
@ufreier
you are welcome
pcahyna commented at 2023-11-22 10:48:¶
@ufreier how old is ReaR that you are using? Is it the released 2.7, or current development code from GitHub? With the current code, USE_SERIAL_CONSOLE='no' should not be needed in most cases (after #2961 was merged).
ufreier commented at 2023-11-22 16:52:¶
I use ReaR from the Debian repository (simply 'apt install rear') but I'll check the latest version from here.
pcahyna commented at 2023-11-22 17:30:¶
@ufreier I believe this may explain it, please try the latest sources without USE_SERIAL_CONSOLE='no' ( here's how to use ReaR from Git sources instead from a package: https://github.com/rear/rear/#quick-start-guide )
ufreier commented at 2023-11-25 12:26:¶
I can confirm using the latest version USE_SERIAL_CONSOLE='no' is not necessary anymore.
pcahyna commented at 2023-11-27 10:32:¶
thank you @ufreier for the test, I am glad that we now understand the problem and have a fix in the devel version.
kronenpj commented at 2023-12-04 03:15:¶
I believe I was having the same problem and the code in git as of now (rear-2.7-1.git.2.0fd8a77a.master) works far better than 2.6 on Fedora 39. I look forward to this being picked up by Fedora's repositories. :)
tbsky commented at 2023-12-07 09:00:¶
Hi:
I was curious what need to be fixed to prevent the issue. so I ask at
systemd mail list. it seems rear itself need to handle the
situation...
https://lists.freedesktop.org/archives/systemd-devel/2023-November/049676.html
jsmeix commented at 2023-12-07 10:29:¶
Excerpts from
https://lists.freedesktop.org/archives/systemd-devel/2023-November/049676.html
Those libraries are not found by ldd because
they are not in the public library search path.
...
Those libraries have an unstable ABI,
so they are tucked away in a separate directory
and are not intended to be found during a search
When intentionally libraries cannot be found by 'ldd'
then such libraries must be explicitly specified
via LIBS, see its description in default.conf
e.g. for ReaR 2.7 online starting at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L1517
tbsky commented at 2023-12-08 05:23:¶
Hi:
I don't know if systemd is meant to be "Special library files" as
described in the default.conf. since systemd is used by most
distributions, every user will need to handle that. I just thought if
distribution packager or rear itself can do something so users won't
need to take care of systemd issues in the future.
jsmeix commented at 2023-12-08 07:45:¶
I meant that ReaR will have to be enhanced
to somehow deal with newer systemd's "hidden" libraries.
We have some code to include systemd into the ReaR recovery system
and that code would have to be somehow enhanced because that code
is meant to get some consistent systemd things (minimal as needed)
into the ReaR recovery system.
Currently with newer systemd things are inconsistent in the
ReaR recovery system (some "hidden" libraries are missing)
so the missing things must be added to the ReaR recovery system.
Until the ReaR upstream GitHub master code was enhanced
to properly deal with newer systemd's "hidden" libraries
all users with newer systemd and older or current ReaR
need to manually specify the missing libraries via LIBS
as I described above in
https://github.com/rear/rear/issues/3021#issuecomment-1609096312
FWIW:
I think LD_PRELOAD stuff doesn't solve it because
I don't see how that makes the missing libraries
get included in the ReaR recovery system.
I fear LD_PRELOAD stuff only makes "rear recover" don't fail
but I don't see how that also makes "rear recover" work?
I don't see "rear recover" mentioned in the comments above.
But this is only what I think off the top of my head.
I did not test with newer systemd.
I only did
https://github.com/rear/rear/issues/3021#issuecomment-1609283508
Even if LD_PRELOAD stuff solves it
I think specifying the missing libraries via LIBS
is the right method in ReaR that is meant for such things
while LD_PRELOAD stuff would implement RFC1925 item (6a).
zDEFz commented at 2023-12-08 10:41:¶
I meant that ReaR will have to be enhanced to somehow deal with newer systemd's "hidden" libraries. We have some code to include systemd into the ReaR recovery system and that code would have to be somehow enhanced because that code is meant to get some consistent systemd things (minimal as needed) into the ReaR recovery system. Currently with newer systemd things are inconsistent in the ReaR recovery system (some "hidden" libraries are missing) so the missing things must be added to the ReaR recovery system.
Until the ReaR upstream GitHub master code was enhanced to properly deal with newer systemd's "hidden" libraries all users with newer systemd and older or current ReaR need to manually specify the missing libraries via LIBS as I described above in #3021 (comment)
FWIW: I think LD_PRELOAD stuff doesn't solve it because I don't see how that makes the missing libraries get included in the ReaR recovery system. I fear LD_PRELOAD stuff only makes "rear recover" don't fail but I don't see how that also makes "rear recover" work? I don't see "rear recover" mentioned in the comments above. But this is only what I think off the top of my head. I did not test with newer systemd. I only did #3021 (comment) Even if LD_PRELOAD stuff solves it I think specifying the missing libraries via LIBS is the right method in ReaR that is meant for such things while LD_PRELOAD stuff would implement RFC1925 item (6a).
As said, the only thing fixing it for me was to edit the rear script and
add
export LD_PRELOAD=/usr/lib64/systemd/libsystemd-shared-253.10-1.fc38.so
kronenpj commented at 2023-12-08 14:45:¶
After playing around for a bit, the only way I was able to remove the
error was using a file in /etc/ld.so.conf.d. Adding entries to LIBS,
COPY_AS_IS and others didn't work. I believe that's because even when
the files exist in the correct path, the test and subsequent ISO-booted
system doesn't know to look there.
On my Fedora system, an ldd /usr/lib/systemd/systemd shows:
# ldd /usr/lib/systemd/systemd
linux-vdso.so.1 (0x00007ffd42e1f000)
libsystemd-core-254.7-1.fc39.so => /usr/lib64/systemd/libsystemd-core-254.7-1.fc39.so (0x00007f8e19600000)
libsystemd-shared-254.7-1.fc39.so => /usr/lib64/systemd/libsystemd-shared-254.7-1.fc39.so (0x00007f8e19200000)
...
But the systemd executable is only added to the initrd.cgz file when
the file referencing /usr/lib64/systemd is present in
/etc/ld.so.conf.d.
I hope this helps.
rasa commented at 2023-12-28 00:07:¶
To be clear, the command
sudo tee <<<'/usr/lib/x86_64-linux-gnu/systemd' /etc/ld.so.conf.d/x86_64-linux-gnu-systemd.conf
sudo ldconfig
removed the error message from the logs, on Ubuntu 23.10 (Mantic).
schlomo commented at 2024-01-29 17:45:¶
It seems like a possible "root cause" could be the fact that our way of
checking for hidden library dependencies with cd and ldd doesn't
work in all cases
https://github.com/rear/rear/blob/58d6ec23941557af097def87ea25b13d340f834a/usr/share/rear/build/default/990_verify_rootfs.sh#L179
Maybe a solution would be to search for all lib* directories in the
rescue system and use them as LD_LIBRARY_PATH? Or is that too extreme?
I think that there is value to removing such false warnings as they tend to confuse or scare users. And they make it so much harder to pick up real errors.
github-actions commented at 2024-03-30 01:59:¶
Stale issue message
schlomo commented at 2024-04-12 14:58:¶
@rear/contributors I think that this problem is somewhat specific to Systemd after a certain version, at least 252 and later show this. The general problem is "hidden" libraries and we won't be able to solve it in a generic fashion.
For quite some proprietary backup software we already added support for
a "custom" LD_LIBRARY_PATH and I would suggest extending that
mechanism to also include a customer LD_LIBRARY_PATH for Systemd to
satisfy our ldd validation. It won't affect the rescue system if we do
it only in ReaR itself for the validation of libraries.
Maybe in the future we will meet more "special" standard software that needs a custom library path, and then we should again accomodate it.
GreasyMonkee commented at 2024-05-28 03:28:¶
I found this post that offered some "solutions." Even though the question was asked for Ubuntu, I found it helpful for Debian.
TL;DR
One-off solution:
sudo bash -c "LD_PRELOAD=/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-252.so" rear -v mkbackup(untested)... OR ...
create an file in
/etc/ld.so.conf.d(This is the method I chose.)I created
/etc/ld.so.conf.d/libsystemd-core.conf... into which I put/usr/lib/x86_64-linux-gnu/systemdI then ransudo ldconfigA run of
ldd /usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-252.sonow resolveslibsystemd-shared-252.soI rebooted for good measure and ran a straight
rear -v mkbackup-- it ran flawlessly.I suppose why
libsystemd-core-252.sohas this issue is a question for the distro and subsystem teams.
Fedora 41 (Rawhide) using libsystemd-256-rc2-1 has the same behaviour.
Applied Liam Fry's fix of creating
/etc/ld.so.conf.d/libsystemd-core.conf ... into which I put
/usr/lib64/systemd I then ran sudo ldconfig has given a clean
creation of the Backup image.
Many thanks for the whole team here for their contributions.
Cheers,
Garth.
schlomo commented at 2024-05-28 07:53:¶
Thank you @GreasyMonkee for the test on Rawhide. I think that we should
note that the libsystemd-shared library is private to systemd and
therefore not part of the regular library search path. ReaR shows an
error because ReaR checks all binaries for library dependencies and we
need to extend that mechanism to also properly handle private libraries.
As a workaround I think it is OK to modify/hack ReaR - I'd caution against modifying the system in a way that works against the systemd design of keeping this library private. Maybe it has no negative side effect, but maybe it can do more harm somewhere else where you didn't expect it.
GreasyMonkee commented at 2024-05-28 10:25:¶
Thank you @GreasyMonkee for the test on Rawhide. I think that we should note that the
libsystemd-sharedlibrary is private to systemd and therefore not part of the regular library search path. ReaR shows an error because ReaR checks all binaries for library dependencies and we need to extend that mechanism to also properly handle private libraries.As a workaround I think it is OK to modify/hack ReaR - I'd caution against modifying the system in a way that works against the systemd design of keeping this library private. Maybe it has no negative side effect, but maybe it can do more harm somewhere else where you didn't expect it.
Yes, agreed. I will be keeping an eye on how things behave over the coming months, if any issues crop up, shall let you know.
jsmeix commented at 2024-06-13 08:38:¶
By chance I needed to try out ReaR on a Fedora 40 system, see
https://github.com/rear/rear/pull/3175#issuecomment-2163116469
and subsequent comments therein and see also
https://github.com/rear/rear/issues/3247
So I experienced this issue here myself.
What I found out:
With some recent systemd version
'rear -D mkrescue' shows something like:
Testing each binary with 'ldd' and look for 'not found' libraries within the recovery system
/usr/lib64/systemd/libsystemd-core-255.4-1.fc40.so requires additional libraries
libsystemd-shared-255.4-1.fc40.so => not found
ReaR recovery system in '/var/tmp/rear.nHDN0gSTgC8zE80/rootfs' needs additional libraries, check /root/rear.github.master/var/log/rear/rear-linux.log for details
But
COPY_AS_IS+=( /usr/lib64/systemd/ )
does not help because those libraries
get already automatically included via
('rear -D mkrescue' log file excerpts)
+ source /root/rear.github.master/usr/share/rear/build/GNU/Linux/100_copy_as_is.sh
...
... Adding required library '/usr/lib64/systemd/libsystemd-core-255.4-1.fc40.so' to LIBS
... Adding required library '/usr/lib64/systemd/libsystemd-shared-255.4-1.fc40.so' to LIBS
So one gets them in the ReaR recovery system
# find /var/tmp/rear.nHDN0gSTgC8zE80/rootfs/ -type f | grep libsystemd-
/var/tmp/rear.nHDN0gSTgC8zE80/rootfs/usr/lib64/systemd/libsystemd-core-255.4-1.fc40.so
/var/tmp/rear.nHDN0gSTgC8zE80/rootfs/usr/lib64/systemd/libsystemd-shared-255.4-1.fc40.so
Also something like
NON_FATAL_BINARIES_WITH_MISSING_LIBRARY='systemd/libsystemd-core'
does not help to silence the message because
usr/share/rear/build/default/990_verify_rootfs.sh
has a comment that explains
# Only for programs (i.e. files in a .../bin/... or .../sbin/... directory) treat a missing library as fatal
So - at least for now - a message like
/usr/lib64/systemd/libsystemd-core-255.4-1.fc40.so requires additional libraries
libsystemd-shared-255.4-1.fc40.so => not found
can only be ignored.
It is some kind of "false positive" but currently
I have no good idea how to avoid that without
breaking the intent of that verification step
i.e. without the risk of getting "false negatives"
which would be worse that this "false positive".
Here "positive" and "negative" are meant
regarding the test to report missing libraries, i.e.
"positive" means it correctly reported a missing library
"negative" means it correctly did not report a library
that can be found in the ReaR recovery system.
jsmeix commented at 2024-06-13 12:00:¶
Only a totally untested offhanded idea
how to possibly solve such issues generically:
The crucial part here is that
libsystemd-shared is needed by libsystemd-core
but libsystemd-shared cannot be found as usual (i.e. by 'ldd')
regardless that libsystemd-shared exists in the
ReaR recovery system.
So my basic idea is to add a verification step
that tests whether or not a library that is needed
but cannot be found by usual means (i.e. by 'ldd')
exists nevertheless in the ReaR recovery system.
When it exists nevertheless in the ReaR recovery system
we may sufficiently safely assume that things are OK
and not report that library as missing.
jsmeix commented at 2024-06-14 13:40:¶
https://github.com/rear/rear/pull/3250
implements
https://github.com/rear/rear/issues/3021#issuecomment-2165453757
jsmeix commented at 2024-06-18 11:49:¶
With
https://github.com/rear/rear/pull/3250
merged this issue should be sufficiently solved.
[Export of Github issue for rear/rear.]