#2270 PR closed: Fix for CentOS 7.7 and 8.0 where certain programs (e.g. dhclient) require additional libraries¶
Labels: enhancement, bug, documentation,
won't fix / can't fix / obsolete
DamaniN opened issue at 2019-10-30 04:30:¶
Pull Request Details:¶
-
Type: Enhancement
-
Impact: Normal
-
Reference to related issue (URL):
#2266
- How was this pull request tested?
Used rear mkrescue to successfully create an ISO both from the command
line and via CDM's fileset pre-scripts on CentOS 7.7 and 8.0.
Successfully booted the CentOS 7.7 ISO.
- Brief description of the changes in this pull request:
Added LD_LIBRARY_PATH information to the CDM documentation.
jsmeix commented at 2019-11-04 12:43:¶
@rear/contributors
I would like to have a review by another ReaR maintainer
in particular the export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:..." part.
I think this is not yet the right solution but only a workaround for
now
because I guess in CentOS 7.7 and 8.0 this is done differently
so a review from a CentOS 7.7 and 8.0 user would be much appreciated.
Basically in the ReaR recovery system things should be done same
as on the original CentOS 7.7 and 8.0 systems.
So if on the original CentOS 7.7 and 8.0 systems things are done via
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:...
the same should be automatically done in the ReaR recovery system
and when on the original CentOS 7.7 and 8.0 systems things are done
differently things should be done same in the ReaR recovery system.
jsmeix commented at 2019-11-08 13:55:¶
In general regarding a global export LD_LIBRARY_PATH="...":
Setting a global LD_LIBRARY_PATH leads to unexpected side effects
because libraries via LD_LIBRARY_PATH have precedence
over the normal/default system libraries so that
after export LD_LIBRARY_PATH="..." all programs
are run with the special libraries in LD_LIBRARY_PATH
and not with the normal/default system libraries.
In particular export LD_LIBRARY_PATH="..." in etc/rear/local.conf
let all programs in all ReaR scripts run with the special libraries
in LD_LIBRARY_PATH and not with the normal system libraries
so that the programs could behave different when run "in ReaR"
compared to when run directly on the system.
Cf.
https://github.com/rear/rear/issues/1533#issuecomment-336622504
https://github.com/rear/rear/pull/1562#issuecomment-342111737
https://github.com/rear/rear/issues/1927#issuecomment-434224424
https://github.com/rear/rear/issues/1907#issuecomment-434215448
https://www.hpc.dtu.dk/?page_id=1180
where the latter reads in particular (excerpts):
LD_LIBRARY_PATH – or: How to get yourself into trouble!
...
LD_LIBRARY_PATH tells the dynamic link loader ...
where to search for the dynamic shared libraries
an application was linked against ...
and this list is then searched
before the compiled-in search path(s),
and the standard locations (typically /lib, /usr/lib, ...)
...
It is even getting worse, if this crutch is applied
globally into an user’s (or the system’s!) environment
...
Inconsistency:
This is the most common problem.
LD_LIBRARY_PATH forces an application
to load a shared library it wasn’t linked against,
and that is quite likely not compatible with
the original version.
This can either be very obvious,
i.e. the application crashes,
or it can lead to wrong results, if the
picked up library not quite does what the
original version would have done.
Especially the latter is sometimes hard to debug.
DamaniN commented at 2019-11-15 20:51:¶
@jsmeix, so what is a more appropriate way to resolve this issue? I don't have much experience in how to tell ReaR where to look for libraries if it cannot find them in the default paths.
jsmeix commented at 2019-11-18 11:21:¶
@DamaniN
see
https://github.com/rear/rear/issues/2266#issuecomment-554971616
The real fix should be to properly
replicate in the ReaR recovery system
the config of the run-time linker (for /sbin/dhclient)
from the config on the original CentOS system
jsmeix commented at 2019-11-21 09:30:¶
@DamaniN
I guess you closed this pull request because
you are now trying to get this issue solved in a different way?
DamaniN commented at 2019-11-22 02:50:¶
That pull request had an extra commit from #2267 in it. I removed the commit for this issue to allow it to close and merge. I haven't found a better fix for this yet and will repost the original shortly.
[Export of Github issue for rear/rear.]