#2117 PR merged: Fix for issue 2116: added new SUSE-specific script to call 'shim-inst…

Labels: enhancement, bug, fixed / solved / done

petroniusniger opened issue at 2019-04-12 16:05:

Pull Request Details:

By installing a Leap15 VM, creating a recovery ISO + backup archive with the modified version of ReaR (official 2.4 + my changes), then shutting down the VM, deleting its disk image, recreating a new disk (same size in this case), booting the VM on the recovery ISO and running "rear recover".

  • Brief description of the changes in this pull request:

New script (usr/share/rear/finalize/SUSE_LINUX/i386/640_install_shims.sh) that calls 'shim-install' inside a chroot on the recovered system, and uses the (sed-processed) /boot/grub2/grub.cfg as input to recreate 2 needed EFI files:

/boot/grub2/x86_64-efi/core.efi
/boot/efi/EFI/opensuse/grubx64.efi

(both files are binary-identical, by the way).

jsmeix commented at 2019-04-15 09:45:

@petroniusniger
thank you for your pull request.

I will have a look as time permits - could be delayed e.g. until Wednesday
(we have Easter school holidays in Germany and my kids take precedence :-)

jsmeix commented at 2019-04-15 13:39:

@petroniusniger
some things have changed in the finalize scripts since ReaR 2.4,
cf. https://github.com/rear/rear/issues/2045
and its https://github.com/rear/rear/pull/2047
where in particular the bootloader install scripts were renumbered
and things like https://github.com/rear/rear/pull/2055

Accordingly based on your
https://github.com/rear/rear/pull/2117/files
I made a not yet tested preliminary
usr/share/rear/finalize/SUSE_LINUX/i386/665_install_shim.sh
that should (hopefully) better match the current code:

665_install_shim.sh.txt

I would appreciate it if you could have a look at it
and tell me what you think about it.

petroniusniger commented at 2019-05-16 15:13:

@jsmeix
I reviewed your proposed '665_install_shim.sh.txt' and it looked OK to me at first sight.
I then set about to test it. It doesn't work, unfortunately, BUT it also allowed me to better understand the situation in which this shim file recreation is necessary.

Here is what I did:

  • I first realigned my working copy by merging changes from "trunk/LATEST" (so I'm now "beyond" 2.5)
  • then I put this working copy inside my test VM
  • inside the working copy, I removed my own version of the script and replaced it with yours (called '665_install_shim.sh')
  • I then generated a new recovery image + backup from within that working copy ('./usr/sbin/rear -v mkbackup')

I then proceeded to test recovery of the VM (delete and recreate disk image, boot on recovery media). While doing this, I noticed the following problems (or simple change in behaviour):

  • the new script '665_install_shim.sh' now runs before '670_run_efibootmgr.sh'
  • new script '665_install_shim.sh' fails with error message:
    "Cannot install secure boot loader (shim) because GRUB2 was not
    successfully installed"

So I thought that my recovered VM would fail to boot, but it did!

Then I thought I would redo the test, but this time creating a slightly larger disk image after deleting it (because I noticed that no 'sed' replacement took place in '/boot/grub2/grub.cfg' during my first test). This time, the behaviour of '665_install_shim.sh' was exactly the same (same error message), but the volume group had been recreated from scratch instead of performing a "vgrestore", which means the UUIDs were indeed different now, and the VM no longer booted.

I'll recover it manually tomorrow, and start investigating why ReaR reports failing to install GRUB2, whereas that component is obviously present in the recovered VM and seems to be functional.

petroniusniger commented at 2019-05-17 09:28:

OK, I now understand the reason for the failure:

  • grub2 is meant to be installed by 'finalize/Linux-i386/660_install_grub2.sh' but this script aborts if $USING_UEFI_BOOTLOADER is true, which is the case for us => 660_install_grub2.sh does nothing (as confirmed by the absence of any message in the log)
  • a comment in the grub2 install script mentions that 'finalize/Linux-i386/670_run_efibootmgr.sh' is to be used instead when $USING_UEFI_BOOTLOADER is true and this script does indeed run successfully based on the recovery log and it does set $NOBOOTLOADER to empty (meaning success)
  • BUT: 665_install_shim.sh now runs before 670_run_efibootmgr.sh, hence the fact that it doesn't do anything!

I'll now perform a new test renaming 665_install_shim.sh to 675_install_shim.sh

petroniusniger commented at 2019-05-17 11:50:

I'm happy to confirm that all works as expected after having renamed the script to '675_install_shim.sh' (thereby making sure it executes after 670_run_efibootmgr.sh).

I will now commit the changes and push them to branch issue-2116.

jsmeix commented at 2019-05-17 13:48:

@petroniusniger
many thanks for all your work and in particular for your explanatory comments.
I appreciate it because it makes it so much easier for me to understand things.
As time permits I will have a closer look next week...

jsmeix commented at 2019-05-17 14:24:

@rmetrich
could you have a look here, perhaps it is also of interest for Red Hat?
With this current pull request ReaR woud get a new SUSE specific
usr/share/rear/finalize/SUSE_LINUX/i386/675_install_shim.sh
but I wonder if something similar isn't also needed for Red Hat?

rmetrich commented at 2019-05-17 14:34:

@pcahyna Could you confirm this kind of code is not needed on RHEL8?

pcahyna commented at 2019-05-17 14:41:

I think this would be discovered in our downstream testing if needed, @xjezda00 what do you think?

jsmeix commented at 2019-05-24 10:54:

I will merge it in its current form right now.

If we need it in general we can move it
from finalize/SUSE_LINUX/i386/675_install_shim.sh
to finalize/Linux-i386/675_install_shim.sh
or link to it like
finalize/Fedora/i386/675_install_shim.sh -> ../../SUSE_LINUX/i386/675_install_shim.sh
or whatever else fits our needs.

jsmeix commented at 2019-05-24 11:24:

@petroniusniger
thank you for your contribution that improves ReaR.

[Export of Github issue for rear/rear.]