Bug 1498748 - Grub bootloader is not set after restore from ReaR backup
Summary: Grub bootloader is not set after restore from ReaR backup
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rear
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Pavel Cahyna
QA Contact: BaseOS QE - Apps
Petr Bokoc
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-05 07:18 UTC by Dmitry Zhukovski
Modified: 2018-12-14 16:34 UTC (History)
2 users (show)

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).
Clone Of:
Environment:
Last Closed: 2018-10-30 12:01:29 UTC
Target Upstream Version:


Attachments (Terms of Use)

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 .))


Note You need to log in before you can comment on or make changes to this bug.