You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With current ReaR github master code
build/GNU/Linux/100_copy_as_is.sh can get in conflict
with what rescue/default/010_merge_skeletons.sh did before
when the COPY_AS_IS array contains a symlink to a directory
that was already created in ROOTFS_DIR by 010_merge_skeletons.sh
# usr/sbin/rear -D mkrescue
...
Copying files and directories
ERROR: Failed to copy files and directories in COPY_AS_IS minus COPY_AS_IS_EXCLUDE
Some latest log messages since the last called script 100_copy_as_is.sh:
2019-05-02 11:55:13.392080693 Entering debugscripts mode via 'set -x'.
2019-05-02 11:55:13.396251035 Copying files and directories
2019-05-02 11:55:13.400265205 Files being copied: /root/rear.github.master/usr/share/rear /root/rear.github.master/var/lib/rear /dev /etc/inputrc /etc/protocols /etc/services /etc/rpc /etc/termcap /
2019-05-02 11:55:13.402776151 Files being excluded: dev/shm dev/oracleasm dev/mapper dev/.udev /root/rear.github.master/var/lib/rear/output/rear-g243.iso dev/shm/* /etc/pki/tls/private /etc/pki/CA/p
tar: Removing leading `/' from member names
tar: etc/scripts: Cannot open: File exists
tar: Removing leading `/' from hard link targets
tar: Exiting with failure status due to previous errors
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-g243.log for details
I think as the current code is it is even good that it fails
in this particular case.
This particular case is only the tip of an iceberg:
In other cases it just blindly proceeds and COPY_AS_IS array elemets
can just overwrite anything that was already created in ROOTFS_DIR
by 010_merge_skeletons.sh - i.e. COPY_AS_IS can destroy needed
recovery system content.
# usr/sbin/rear -D mkrescue
...
Copying files and directories
Copying binaries and libraries
...
Running exit tasks
You should also rm -Rf /tmp/rear.CdodUBnLMNMmf3m
but now etc/scripts/system-setup in the recovery system
is overwritten by the content from /etc/scripts/system-setup
on the original system
I think we should test in build/GNU/Linux/100_copy_as_is.sh
if directories are already there and when files that are already there
would be overwrtitten.
The text was updated successfully, but these errors were encountered:
See
#2132 (comment)
for the original issue.
With current ReaR github master code
build/GNU/Linux/100_copy_as_is.sh can get in conflict
with what rescue/default/010_merge_skeletons.sh did before
when the
COPY_AS_IS
array contains a symlink to a directorythat was already created in ROOTFS_DIR by 010_merge_skeletons.sh
Example:
and in etc/rear/local.conf
results
I think as the current code is it is even good that it fails
in this particular case.
This particular case is only the tip of an iceberg:
In other cases it just blindly proceeds and
COPY_AS_IS
array elemetscan just overwrite anything that was already created in ROOTFS_DIR
by 010_merge_skeletons.sh - i.e.
COPY_AS_IS
can destroy neededrecovery system content.
Example:
and in etc/rear/local.conf
results
but now
etc/scripts/system-setup
in the recovery systemis overwritten by the content from /etc/scripts/system-setup
on the original system
I think we should test in build/GNU/Linux/100_copy_as_is.sh
if directories are already there and when files that are already there
would be overwrtitten.
The text was updated successfully, but these errors were encountered: