After install SYMCsdcss on suse 11.4 the server reboots using rear

[mackIaud]

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"):

xfafhfiha001:/var/log/rear # /usr/sbin/rear -V
Relax-and-Recover 2.4 / 2018-06-21

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

xfafhfiha001:/var/log/rear # cat /etc/os-release
NAME="SLES"
VERSION="11.4"
VERSION_ID="11.4"
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:11:4"

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

• Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
  Product Name: ProLiant DL360 Gen9

• System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
  Linux xfafhfiha001 3.0.101-357.g64d2b6f-default Pull fixes for partitioning and udev. #1 SMP Tue May 16 14:40:08 UTC 2017 (64d2b6f) x86_64 x86_64 x86_64 GNU/Linux
  rear-xfafhfiha001.log

rear-xfafhfiha001.log.zip

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

# This file has been transformed by /sbin/elilo.
# Please do NOT edit here -- edit /etc/elilo.conf instead!
# Otherwise your changes will be lost e.g. during kernel-update.
#
# Modified by YaST2. Last modification on jue may 18 17:12:28 BST 2017
timeout = 80
##YaST - boot_efilabel = "SLES for SAP Applications"
default = Linux
prompt

image = vmlinuz-3.0.101-357.g64d2b6f-default
###Don't change this comment - YaST2 identifier: Original name: linux###
    label = Linux
    description = "Linux (3.0.101-357.g64d2b6f-default)"
    append = "resume=/dev/rootvg/swapvol splash=silent crashkernel=256M-:128M showopts intel_idle.max_cstate=0 processor.max_cstate=0 "
    initrd = initrd-3.0.101-357.g64d2b6f-default
    root = /dev/rootvg/rootvol

image = vmlinuz-3.0.101-357.g64d2b6f-default
###Don't change this comment - YaST2 identifier: Original name: failsafe###
    label = Failsafe
    description = "Failsafe (3.0.101-357.g64d2b6f-default)"
    append = "showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe    "
    initrd = initrd-3.0.101-357.g64d2b6f-default
    root = /dev/rootvg/rootvol

• Storage (lokal disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
  local disk and SAN FC with multipath with dm-
• Description of the issue (ideally so that others can reproduce it):
  I had rear installed on a server with suse 11.4 and runned ok, but after install this antivirus from symantec "SYMCsdcss-6.7.0-859" now the server reboots using rear.

xfafhfiha001:/var/log/rear # rpm -qa |grep -i sdcs
SYMCsdcss-6.7.0-859

When rear is Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression the server restart automatically.

2019-01-23 07:00:43.055773310 Including build/default/990_update_os_conf.sh
2019-01-23 07:00:43.058115331 Finished running 'build' stage in 21 seconds
2019-01-23 07:00:43.060335608 ======================
2019-01-23 07:00:43.061970887 Running 'pack' stage
2019-01-23 07:00:43.063890174 ======================
2019-01-23 07:00:43.075408403 Including pack/Linux-i386/300_copy_kernel.sh
2019-01-23 07:00:43.082244639 Including pack/GNU/Linux/400_guess_kernel.sh
2019-01-23 07:00:43.085244599 Guessed kernel /boot/vmlinuz-3.0.101-357.g64d2b6f-default
2019-01-23 07:00:43.091897342 Including pack/GNU/Linux/900_create_initramfs.sh
2019-01-23 07:00:43.098023687 Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression

We saw in the log that the antivirus installed new modules in the kernel that were unsupported.

FATAL: module '/lib/modules/3.0.101-357.g64d2b6f-default/kernel/drivers/sisfim.ko' is unsupported
Use --allow-unsupported or set allow_unsupported_modules to 1 in
/etc/modprobe.d/unsupported-modules
FATAL: module '/lib/modules/3.0.101-357.g64d2b6f-default/kernel/drivers/sisips.ko' is unsupported
Use --allow-unsupported or set allow_unsupported_modules to 1 in
/etc/modprobe.d/unsupported-modules 

I changed the configuration and althought doesn' t appear this message now the server still rebooting using rear.

• Workaround, if any:
  Disable rear

• Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
  I attach the logs when worked ok and when I have problems.

[gdha]

@mackIaud Any suspicious found in the system logs?

[mackIaud]

Hi,

In messages there' s no log before reboot ejecutin rear using cron.
reboot system boot 3.0.101-357.g64d Wed Jan 23 07:22 - 13:25 (37+06:02)

Jan 23 07:00:01 xfafhfiha001 /usr/sbin/cron[25506]: (root) CMD (/usr/sbin/rear mkbackup -c /etc/rear/conf_rsync/ )
Jan 23 07:00:01 xfafhfiha001 /usr/sbin/cron[25507]: (root) CMD (/opt/osit/ESAR/sysdowntime/bin/start.sh >/dev/null 2>&1)
Jan 23 07:22:27 xfafhfiha001 syslog-ng[4962]: syslog-ng starting up; version='2.0.9'

[jsmeix]

@mackIaud
the code that runs for the ReaR log message

Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression

is in usr/share/rear/pack/GNU/Linux/900_create_initramfs.sh
this part

REAR_INITRD_FILENAME="initrd.cgz"
LogPrint "Creating recovery/rescue system initramfs/initrd $REAR_INITRD_FILENAME with gzip default compression"
if find . ! -name "*~" | cpio -H newc --create --quiet | gzip > "$TMP_DIR/$REAR_INITRD_FILENAME" ; then

i.e. it is basically this command

find . ! -name "*~" | cpio -H newc --create --quiet | gzip

Nothing therein indicates in any way that reboot could be called.

What I think because of

I had rear installed on a server with suse 11.4 and runned ok,
but after install this antivirus from symantec "SYMCsdcss-6.7.0-859"
now the server reboots using rear.
...
the antivirus installed new modules in the kernel that were unsupported.

it seems much more that what you call 'reboot' is not a reboot call
but actually your system crashes hard e.g. a kernel panic or worse,
with 'worse' I mean a sudden kernel stop without kernel error messages
and then your system boots anew.

From my currnet point of view the root cause is not inside ReaR
but something outside, e.g. broken kernel modules or whatever
caused by bad third party software.

FWIW:
We had already such kind of issues with bad third party software,
for example see the comments about "Storix" in
#1796 in particular
#1796 (comment)

[mackIaud]

Thanks for the answer I thing the same, but we told to this to symantech support and they told to us that his product is support with suse 11.4.
There' s an option to disable module online before start de rear We will try it and I will update the case.

Regards.

[jsmeix]

No news is good news.