New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing libraries in the recovery system for symlinks in COPY_AS_IS #3064
Comments
For now "discuss / RFC" until we came to a conclusion Regardless that I did a lot of code changes related Excerpt from default.conf:
I fear that |
The problem is, even if |
@jsmeix without this exception, we would have the same problem even for non-symlinks and ReaR would fail all the time. |
@pcahyna I do not argue against further enhancing the COPY_AS_IS code I only like to provide some reasoning for the current behaviour. |
@pcahyna
I think you see and understand this shortcoming |
@jsmeix, maybe I was wrong. Without this exception, what I get are these additional messages (which are not fatal errors):
I don't know whether this indicates a real problem in the recovery system or not (that is, whether e.g. |
I would say though that by default executables under |
A totally offhanded and untested idea Copy executables in COPY_AS_IS to PROGS My assumption is that handling arbitrary files If my assumption holds, this could much clean up I think duplicate entries should be filtered out |
The problem is, PROGS is intended for executables in $PATH, while we are using COPY_AS_IS for helper executables outside $PATH (under A program in PROGS will be unconditionally copied to |
Yes, sigh! So currently our only way out is to more and more enhance @pcahyna Then let's just wait and see how things behave in general A general addedum: From my curent point of view our whole "copy things" code I think the root cause is that currently the ReaR recovery system This leads to the (apparently at least in practice unsolvable?) Cf. the part about symbolic links
A self-consistent copy also means that linked libraries I think other required things to get a self-consistent copy |
@jsmeix (or anyone else), have you ever considered using dracut to generate the ReaR initrd? It is a tool that generates the initrd on Fedora (and probably some other distros). I would prefer to focus on areas where ReaR is really unique (mainly, layout saving and restoration) and leave the "boring work" of constructing the initrd to something else, if possible. |
@pcahyna I fully agree with you to use as much as possible I never considered using dracut to generate the ReaR initrd. Caution! ;-) Based on our findings and assumptions in Make ReaR's initrd as an enhancement of the already existing
My reasoning is same as in When the initrd of the Linux distribution Another (hopefully reasonable) assumption is that So only adding ReaR's specific additional stuff I.e. my "totally offhanded and untested idea" is |
@jsmeix using an already existing initrd would have the advantage of not relying on a specific tool (dracut), but I am afraid that the original initrd is not just feature complete (although that might be a problem as well, for example I suspect that it does not have the all the kernel modules and firmware), but that it does in fact too much. It needs to activate all the storage on the original disks, mount the rootfs and pivot to it. We need to avoid all this (activating the original storage components should be preferably avoided if you are going to wipe them in the next step), which means that we would not need to just "add ReaR's specific additional stuff" but to remove lots of stuff as well. This would require us to have a good knowledge of the specifics of the particular initrd. |
ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.7 / Git
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.4 Beta (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
empty
Description of the issue (ideally so that others can reproduce it):
When
chkconfig
is installed,rear mkrescue
aborts when validating libraries in the recovery system:libpopt.so.0 is missing. In order to reproduce the problem, no other binary that requires libpopt should be included in the recovery system, otherwise it would pull libpopt and the problem would be hidden. In particular,
rsync
andcryptsetup
use libpopt. Remove them before reproducing the problem.The underlying issue is that
chkconfig
got there as the symlink target of/usr/lib/systemd/systemd-sysv-install
(build/default/490_fix_broken_links.sh
), which got there inbuild/GNU/Linux/100_copy_as_is.sh
because/usr/lib/systemd/systemd-*
is in COPY_AS_IS (seeprep/GNU/Linux/280_include_systemd.sh
).and unlike other code that adds binaries to the recovery system, the
build/GNU/Linux/100_copy_as_is.sh
andbuild/default/490_fix_broken_links.sh
tandem does not add required libraries if COPY_AS_IS contains a symlink.The problematic code is here: https://github.com/rear/rear/pull/1521/files#r1377909379 - it skips library dependency resolution for COPY_AS_IS items that are symlinks.
To trigger the problem, several condition must be met:
COPY_AS_IS
(OTOHPROGS
handles symlinks properly)rsync
andcryptsetup
above)The problem is thus quite rare (
PROGS
are the preferred way to add executables to the recovery system, which works fine), but one can trigger it using something else thanchkconfig
. For example,COPY_AS_IS+=( /usr/bin/cdrecord )
. On RHEL,cdrecord
is a symlink toxorriso
, which needs quite special libraries, so:PROGS+=( cdrecord )
works fine.Workaround, if any:
Add
chkconfig
toPROGS
- this will trigger library dependency resolution for itAttachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
Relevant parts of debug log:
The text was updated successfully, but these errors were encountered: