#2340 Issue closed: SELinux failure upon restoration of system, when choosing the auto-recover option from the grub menu.

Labels: support / question, no-issue-activity

Toure opened issue at 2020-03-11 11:01:

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

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

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

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    KVM guest

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

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

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

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

  • Description of the issue (ideally so that others can reproduce it):
    Using ReaR to backup the system and creating a bootable recovery image, select "Automatic Recover " from the GRUB menu, complete the recovery process and reboot the server. Upon first boot, the system will throw an error from selinux stating that it can not find its policy file.

  • Workaround, if any:
    Selecting manual recovery seem to complete the recovery correctly without any issues, possible race condition.

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
    Working on getting logs.

jsmeix commented at 2020-03-12 14:42:

@Toure
does it behave reproducible?
I.e. when you test it several times does then the issue
always happen when you select Automatic Recover
in the ReaR recovery system bootloader menue
but it never happens when you launch "rear recover" manually?

I ask because I cannot imagine what the reason could be.

As far as I see the only difference between Automatic Recover
and launching "rear recover" manually is coded in
usr/share/rear/skel/default/etc/scripts/system-setup
https://github.com/rear/rear/blob/master/usr/share/rear/skel/default/etc/scripts/system-setup
which is run (as /etc/scripts/system-setup) during ReaR recovery system startup
and all what it does is to launch "rear recover" automatically, so there should
be no difference what "rear recover" does.

For a real analysis inspect your "rear -D recover" debug log files
and compare in particular the SELinux related messages therein
for both cases (i.e. when it fails versus when it works).

Those are the SELinux related files in ReaR:

usr/share/rear/skel/default/selinux
usr/share/rear/restore/default/500_selinux_autorelabel.sh
usr/share/rear/restore/NETFS/default/500_selinux_autorelabel.sh
usr/share/rear/restore/NETFS/Linux-i386/510_selinux_fixfiles_exclude_dirs.sh
usr/share/rear/restore/YUM/default/600_restore_selinux_contexts.sh
usr/share/rear/restore/YUM/default/403_binds_for_selinux.sh
usr/share/rear/restore/FDRUPSTREAM/default/270_selinux_considerations.sh
usr/share/rear/prep/RSYNC/GNU/Linux/200_selinux_in_use.sh
usr/share/rear/backup/RSYNC/GNU/Linux/610_start_selinux.sh
usr/share/rear/backup/RSYNC/GNU/Linux/310_stop_selinux.sh
usr/share/rear/backup/NETFS/GNU/Linux/600_start_selinux.sh
usr/share/rear/backup/YUM/default/600_capture_selinux_contexts.sh

What is actually run in your case depends on your backup/restore method.

I cannot actually help with SELinux specific issues
because I do not use SELinux but I know that every now and then
there have been SELinux related issues with ReaR, cf.
https://raw.githubusercontent.com/rear/rear/master/doc/rear-release-notes.txt
and we have BACKUP_SELINUX_DISABLE
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L1064
but I don't know if that could be at all related to this issue here.

Toure commented at 2020-03-12 15:02:

@jsmeix Thanks for responding I may have found the issue, still testing. It has to do with the option for NETFS:
" # Disable SELinux policy during backup with NETFS or RSYNC (default yes)
BACKUP_SELINUX_DISABLE=1"

I am not sure why this does effect the manual recovery, but if the above flag is disabled, that is if it is set to "0" then the recovery seems to work. As I mentioned I am still trying to test and re-test to make sure, but so far that has been to only fix so far.

gdha commented at 2020-04-15 08:56:

@Toure Strange - the ReaR Automated Testing project is using the automatic recovery for years already and I never had difficulties with SELinux so far.
Did you have the time for doing re-tests? And results to share with us?
Thanks.

github-actions commented at 2020-06-26 01:39:

Stale issue message

Toure commented at 2020-07-07 15:33:

@gdha sorry for the delay we have not been able to reproduce the issue.

[Export of Github issue for rear/rear.]