Hide Forgot
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
(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".
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.
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).
Further analysis in bz1497918#c3
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 .))