Bug 1498748

Summary:	Grub bootloader is not set after restore from ReaR backup
Product:	Red Hat Enterprise Linux 7	Reporter:	Dmitry Zhukovski <dzhukous>
Component:	rear	Assignee:	Pavel Cahyna <pcahyna>
Status:	CLOSED CURRENTRELEASE	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	high	Docs Contact:	Petr Bokoc <pbokoc>
Priority:	unspecified
Version:	7.4	CC:	dzhukous, pcahyna
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	ReaR recovery process fails on non-UEFI systems with the _grub2-efi-x64_ package installed Installing the _grub2-efi-x64_ package, which contains the GRUB2 boot loader for UEFI systems, changes the file `/boot/grub2/grubenv` into a dead absolute symlink on systems which do not use UEFI firmware. When attempting to recover such a system using the ReaR (Relax and Recover) recovery tool, the process fails and the system is rendered unbootable. To work around this problem, do not install the _grub2-efi-x64_ package on systems where it is not required (systems without UEFI firmware).	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-30 12:01:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dmitry Zhukovski 2017-10-05 07:18:57 UTC

Description of problem:
Grub bootloader is not set after restore from ReaR backup

Version-Release number of selected component (if applicable):
rear-2.00-2.el7.x86_64

How reproducible:
everytime

Steps to Reproduce:
1. Backup and restore same machine
2.
3.

Actual results:
system does not boot after it has been recovered with ReaR. Apart from a blinking cursor there is no output on the display. The recovery process exited with the message "Success!".

The system is a Fujitsu TX300S6 with two RAID controllers.


Expected results:
System boots up

Additional info:
One of suspicious messages is about grubenv not being renamed:

2017-08-31 08:30:51 Installing GRUB2 boot loader
Installing for i386-pc platform.
grub2-install: warning: cannot open directory `/usr/share/locale': No such file or directory.
grub2-install: error: cannot rename the file /mnt/local/boot/grub2/grubenv.new to /mnt/local/boot/grub2/grubenv: No such file or directory.
Generating grub configuration file ...
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  /sys//dev/block/8:0: readlink failed: No such file or directory
  /sys//dev/block/8:0: readlink failed: No such file or directory
  /sys//dev/block/8:16: readlink failed: No such file or directory

Comment 23 Pavel Cahyna 2017-11-30 13:24:52 UTC

(In reply to Dmitry Zhukovski from comment #21)

> "rear rescue -v -D" did not work, as can be seen in the attached screenshot.
> We used rear recover –v –D instead.

Sorry that was a mistake, of course I meant "rear recover".

Comment 24 Pavel Cahyna 2017-12-20 14:46:18 UTC

I think /boot/grub2/grubenv is a symlink, and probably a broken one, remove it or make it a regular file (in the running system before making a backup with rear), and repeat the backup and recover procedure, I believe that this will fix the problem.

Please also provide what is the link target, it would be good to know why the link is there in the first place to fix the problem at its root.

Comment 27 Pavel Cahyna 2018-01-22 17:15:28 UTC

I was able to reproduce the problem by installing grub2-efi-x64 on a machine without EFI. A test machine with EFI has this package and the problem does not appear there, grub2-install (which is the problematic command) is not even being run there. The package grub2-efi-x64-modules does not seem to do any harm when installed alone. The problematic symlink is not a dangling symlink in the installed system, but it is one in the rescue environment, as everything is mounted under /mnt/local and the symlink points to an absolute path (i.e. /boot/efi/EFI/redhat/grubenv instead of /mnt/local/boot/efi/EFI/redhat/grubenv).

Comment 28 Pavel Cahyna 2018-01-23 17:49:48 UTC

Further analysis in bz1497918#c3

Comment 29 Pavel Cahyna 2018-10-30 10:53:51 UTC

This bug is seems actually fixed in 7.6 - the fix of bz1497918 is only partial, but sufficient for our purposes - it has converted the absolute symlink to a relative one.

(Also, even without this update, the problem has accidentally disappeared with ReaR 2.4. It turns out that it is sufficient that the directory inside which the symlink points exists and the file will be created. There is a new code in ReaR which creates the /boot/efi/EFI/redhat/ directory (it is  usr/share/rear/build/default/985_fix_broken_links.sh) and `grub2-install --root-directory=/mnt/local /dev/sda" then creates the symlink target /boot/efi/EFI/redhat/grubenv. While this is not the intended behaviour (it is created in the rescue system ramdisk, not in the recovered filesystem), it is probably sufficient. (The 985_fix_broken_links.sh script is actually intended to fix broken links in the rescue initramfs, so it should create the symlink target /boot/efi/EFI/redhat/grubenv, but it has bugs which prevent it, see my comments in https://github.com/rear/rear/pull/1734 .))