#2111 Issue closed: just one more issue with build/default/985_fix_broken_links.sh

Labels: bug, fixed / solved / done

jsmeix opened issue at 2019-04-08 13:02:

  • ReaR version ("/usr/sbin/rear -V"):
    current GitHub master code

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
    SLES11

  • Description of the issue (ideally so that others can reproduce it):

During "rear -D mkbackup" on SLES11 I get in the log (excerpts)

+ source /root/rear-master/rear-master/usr/share/rear/build/default/985_fix_broken_links.sh
...
++ for broken_symlink in '$broken_symlinks'
++ for known_broken_symlink in '$known_broken_symlinks'
++ test ./etc/mtab = ./lib/udev/devices/stdout
+++ readlink -v -e ./lib/udev/devices/stdout
readlink: ./lib/udev/devices/stdout: No such file or directory
++ link_target=
++ test ''
++ LogPrintError 'Broken symlink '\''./lib/udev/devices/stdout'\'' in recovery system because '\''readlink'\'' cannot determine its link target'
++ Log 'Broken symlink '\''./lib/udev/devices/stdout'\'' in recovery system because '\''readlink'\'' cannot determine its link target'
++ echo '2019-04-08 14:33:19.961775889 Broken symlink '\''./lib/udev/devices/stdout'\'' in recovery system because '\''readlink'\'' cannot determine its link target'
2019-04-08 14:33:19.961775889 Broken symlink './lib/udev/devices/stdout' in recovery system because 'readlink' cannot determine its link target
++ PrintError 'Broken symlink '\''./lib/udev/devices/stdout'\'' in recovery system because '\''readlink'\'' cannot determine its link target'
++ for broken_symlink in '$broken_symlinks'
++ for known_broken_symlink in '$known_broken_symlinks'
++ test ./etc/mtab = ./lib/udev/devices/fd
+++ readlink -v -e ./lib/udev/devices/fd
++ link_target=/proc/10596/fd
++ test /proc/10596/fd
+++ dirname /proc/10596/fd
++ mkdir -v -p .//proc/10596
mkdir: created directory `.//proc/10596'
++ cp -v --preserve=all /proc/10596/fd .//proc/10596/fd
cp: cannot stat `/proc/10596/fd': No such file or directory
++ LogPrintError 'Failed to copy symlink target '\''/proc/10596/fd'\'''
++ Log 'Failed to copy symlink target '\''/proc/10596/fd'\'''
++ echo '2019-04-08 14:33:19.965849593 Failed to copy symlink target '\''/proc/10596/fd'\'''
2019-04-08 14:33:19.965849593 Failed to copy symlink target '/proc/10596/fd'
++ PrintError 'Failed to copy symlink target '\''/proc/10596/fd'\'''
++ for broken_symlink in '$broken_symlinks'
++ for known_broken_symlink in '$known_broken_symlinks'
++ test ./etc/mtab = ./lib/udev/devices/core
+++ readlink -v -e ./lib/udev/devices/core
++ link_target=/proc/kcore
++ test /proc/kcore
+++ dirname /proc/kcore
++ mkdir -v -p .//proc
++ cp -v --preserve=all /proc/kcore .//proc/kcore

and at cp ... /proc/kcore it hangs up because that is huge.
On 64-bit systems the size of /proc/kcore is 128TB because that's the limit
of what 64-bit systems can allocate ( 2^47 bytes = 128TiB ), cf.
https://unix.stackexchange.com/questions/116640/what-is-maximum-ram-supportable-by-linux

I think we must never copy stuff from /proc/
into the ReaR recovery system.

I even think we should never copy stuff from /proc/ /sys/ /dev/ and /run/
into the ReaR recovery system.

I will prepare a pull request...

jsmeix commented at 2019-04-09 14:10:

With https://github.com/rear/rear/pull/2112 merged
this issue should be fixed.

[Export of Github issue for rear/rear.]