#2056 Issue closed: ld-2.17.so killed by SIGSEGV

Labels: support / question, fixed / solved / done, external tool, not ReaR / invalid

babadem13 opened issue at 2019-02-27 07:53:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
    Relax-and-Recover 2.4 / Git

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
    OS_VENDOR=RedHatEnterpriseServer
    OS_VERSION=7

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

OUTPUT=ISO
OUTPUT_URL="nfs://nfsadm01p/prear/"
BACKUP=NBU
COPY_AS_IS_NBU=( "${COPY_AS_IS[@]}" /lib/ /lib64/ /usr/lib/ /usr/lib64/ /usr/openv/lib/ /usr/openv/lib/shared/vddk/lib64/ )

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    Linux Virtual Machine on Hyper-V

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86_64 GNU/Linux

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI; GRUB

  • Storage (lokal disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    SAN

  • Description of the issue (ideally so that others can reproduce it):
    "rear mkrescue" itselfs dont get any error messages back. But on some systems we are tracking also the SIGSEGV and there we get email notification (I will attach an email).
    The command that is killed is this one:

/lib/ld-linux.so.2 --verify /usr/lib/modules/3.10.0-957.1.3.el7.x86_64/vdso/vdso32-int80.so

When I execute the command manually I get a "Segmentation fault (core dumped)" error.
If I change the library to the 64bit directory I dont get any error:
image

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

root@lsmon02a:~$ rear -D mkrescue
Relax-and-Recover 2.4 / Git
Using log file: /var/log/rear/rear-lsmon02a.log
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Creating disk layout
Using guessed bootloader 'EFI' (found in first bytes on /dev/sda)
Creating root filesystem layout
Handling network interface 'eth0'
eth0 is a physical device
Handled network interface 'eth0'
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/redhat/grubx64.efi' as UEFI bootloader file
Copying logfile /var/log/rear/rear-lsmon02a.log into initramfs as '/tmp/rear-lsmon02a-partial-2019-02-27T08:49:06+0100.log'
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Copying all files in /lib*/firmware/
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (550572502 bytes) in 82 seconds
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-lsmon02a.iso (569M)
Copying resulting files to nfs location
Saving /var/log/rear/rear-lsmon02a.log as rear-lsmon02a.log to nfs location
Exiting rear mkrescue (PID 36848) and its descendant processes
Running exit tasks
You should also rm -Rf /tmp/rear.s97EOHaNePAkoXs

abrt ld-2.17.so killed by SIGSEGV.txt

jsmeix commented at 2019-02-27 08:55:

@babadem13
when I unzip your attached
https://github.com/rear/rear/files/2909092/abrt.ld-2.17.so.killed.by.SIGSEGV.msg.zip
I get a abrt ld-2.17.so killed by SIGSEGV.msg file - yes, with spaces!
cf. "Use whitespace characters in file names to fool others" in
https://en.opensuse.org/SDB:Plain_Text_versus_Locale
and it seems it contains only some proprietary stuff that I cannot read:

# file 'abrt  ld-2.17.so killed by SIGSEGV.msg'
CDFV2 Microsoft Outlook Message

Please do not waste my time with such proprietary stuff.

Provide a "rear -D mkrescue/mkbackup" debug log file
that is plain ASCII text that everybody can read directly.

I think I know that kind of issue and in my case it was ldd that
got aborted by SIGSEGV ( 139 - 128 = 11 = SIGSEGV):

++ chroot /tmp/rear.G1lIYVh7t7wdjbH/rootfs /bin/bash --login -c 'cd /usr/lib/modules/3.10.0-957.5.1.el7.x86_64/vdso && ldd /usr/lib/modules/3.10.0-957.5.1.el7.x86_64/vdso/vdso.so'
ldd: exited with unknown exit code (139)

In any case it is not a bug inside ReaR when a program that is called
by ReaR gets aborted by SIGSEGV - that is a bug inside that program.

babadem13 commented at 2019-02-27 09:07:

I reattached the mail.

jsmeix commented at 2019-07-09 08:12:

@babadem13
see https://github.com/rear/rear/issues/2177
which is about the same issue.
Therein is an analysis what happens in this particular case and
https://github.com/rear/rear/issues/2177#issuecomment-509500782
is a possible "quick and dirty workaround" in the script
usr/share/rear/build/default/990_verify_rootfs.sh
to avoid this particular issue.

The solution in the next ReaR version to avoid this kind of issues
is to exclude kernel modules from the ldd test in
usr/share/rear/build/default/990_verify_rootfs.sh
because running ldd on kernel modules does not make sense.

jsmeix commented at 2019-07-10 12:42:

With https://github.com/rear/rear/pull/2179 merged
this issue should be avoided.

[Export of Github issue for rear/rear.]