#2062 Issue closed
: After install SYMCsdcss on suse 11.4 the server reboots using rear¶
Labels: support / question
, external tool
, not ReaR / invalid
mackIaud opened issue at 2019-03-01 11:14:¶
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 #1 SMP Tue May 16 14:40:08 UTC 2017 (64d2b6f) x86_64 x86_64 x86_64 GNU/Linux
rear-xfafhfiha001.log
- 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 commented at 2019-03-01 12:13:¶
@mackIaud Any suspicious found in the system logs?
mackIaud commented at 2019-03-01 13:37:¶
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 commented at 2019-03-04 10:42:¶
@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
https://github.com/rear/rear/issues/1796
in particular
https://github.com/rear/rear/issues/1796#issuecomment-387695097
mackIaud commented at 2019-03-11 11:58:¶
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 commented at 2019-04-26 09:34:¶
No news is good news.
[Export of Github issue for rear/rear.]