#2277 PR closed: Search for grub2-mkimage or grub-mkimage in 270_create_grub2_efi_bootloader.sh¶
Labels: enhancement, won't fix / can't fix / obsolete,
minor bug
franciscohosting opened issue at 2019-11-14 16:45:¶
It was hardcoded to search and use grub-mkimage, now it will search for grub2-mkimage and use it if exists
Relax-and-Recover (ReaR) Pull Request Template¶
Please fill in the following items before submitting a new pull request:
Pull Request Details:¶
- Type: Bug Fix / New Feature / Enhancement / Other?
Bug Fix
- Impact: Low / Normal / High / Critical / Urgent
Normal
- Reference to related issue (URL):
https://github.com/rear/rear/issues/2275#issuecomment-553914996
- How was this pull request tested?
Using the proposed pull
- Brief description of the changes in this pull request:
Allowing rear to use and search for grub2-mkimage or grub-mkimage in 270_create_grub2_efi_bootloader.sh
jsmeix commented at 2019-11-15 08:32:¶
@OliverO2
FYI if you like have a look at
https://github.com/rear/rear/pull/2277
because it is about your
output/RAWDISK/Linux-i386/270_create_grub2_efi_bootloader.sh
OliverO2 commented at 2019-11-15 11:36:¶
@jsmeix Thanks for keeping me updated. Actually, I have some local changes from my secure boot experiments hanging around here (not even committed to my local repo). Unfortunately, these changes overlap with this PR.
@franciscohosting, if you are OK with it, I'd like to come up with a
separate PR that would incorporate the requirement to search for
grub2-mkimage. In that case you would no longer need to work on this
PR. I'll promise to finish over the weekend. Please let me know!
OliverO2 commented at 2019-11-15 12:24:¶
I have noticed that
usr/share/rear/prep/GNU/Linux/300_include_grub_tools.sh tries grub
and grub2 prefixes for a number of grub tools, so probably more code
has to be reviewed if any of those tools are used.
franciscohosting commented at 2019-11-15 12:58:¶
@franciscohosting, if you are OK with it, I'd like to come up with a separate PR that would incorporate the requirement to search for
grub2-mkimage. In that case you would no longer need to work on this PR. I'll promise to finish over the weekend. Please let me know!
@OliverO2 Of course! go ahead, I'm new to this, should I close this pull request?
OliverO2 commented at 2019-11-15 13:07:¶
@franciscohosting Thanks for the quick reply. I'll go ahead. I just wanted your confirmation first as I did not want to frustrate you by interfering. Even if you are new to ReaR, everyone here welcomes your contribution! And I know, it's easy to overlook stuff in ReaR, as it has grown over time to a certain level of complexity... ;)
You might close this PR or you might as well wait a bit and see if I did the right thing. Do as you like and have a fantastic weekend!
jsmeix commented at 2019-11-15 13:52:¶
@OliverO2
no, ReaR can't be complex - it's just bash scripts ;-)
@franciscohosting @OliverO2
I wish you a relaxed weekend
https://avatars0.githubusercontent.com/u/1389578?s=200&v=4
franciscohosting commented at 2019-11-15 13:56:¶
@jsmeix @OliverO2 U guys have a nice weekend too!
jsmeix commented at 2019-11-15 14:00:¶
@OliverO2
regarding your
"local changes from my secure boot experiments hanging around"
Currently I am in the process to get a little bit
better understanding of UEFI booting, see
https://github.com/rear/rear/issues/2275#issuecomment-554028783
and subsequent comments
that should (hopefully) result in some cleanup of
how ReaR re-installs the UEFI bootloader pieces.
But I will need some time until I got things sorted out
so that I could implement a proper cleanup,
cf. "Maintain backward compatibility" in
https://github.com/rear/rear/wiki/Coding-Style
So I look forward to your improvements regarding secure boot.
Hopefully we could use same code for same functionality in ReaR.
jsmeix commented at 2019-11-15 14:26:¶
@OliverO2
FYI the reason behind why I think some cleanup of
the UEFI and secure boot related code in ReaR is needed:
While working on an internal SUSE issue I noticed the following
(excerpts from what I wrote in that internal SUSE issue
and adapted to match our current ReaR master code):
That various UEFI related variables in ReaR drive me nuts:
In finalize/Linux-i386/660_install_grub2.sh there is
-------------------------------------------------------
# For UEFI systems with grub2 we should use efibootmgr instead,
# cf. finalize/Linux-i386/670_run_efibootmgr.sh
is_true $USING_UEFI_BOOTLOADER && return
-------------------------------------------------------
Accordingly GRUB2 is not installed when UEFI is used
but instead finalize/Linux-i386/670_run_efibootmgr.sh
is called which sets 'NOBOOTLOADER=' when succeeded.
In the new finalize/SUSE_LINUX/i386/675_install_shim.sh is
-------------------------------------------------------
# USING_UEFI_BOOTLOADER empty or not true means using BIOS:
is_true $USING_UEFI_BOOTLOADER || return 0
-------------------------------------------------------
Accordingly shim is not installed when UEFI is not used
(i.e. shim is only installed when UEFI is used)
but then GRUB2 is not installed (cf. 660_install_grub2.sh above)
and later 675_install_shim.sh contains
-------------------------------------------------------
# Skip if GRUB2 (cf. "GRUB2-EFI" = "$BOOTLOADER" above) was not successfully installed
# because a successfully installed GRUB2 bootloader is a precondition for installing shim.
# In this case NOBOOTLOADER is true, cf. finalize/default/050_prepare_checks.sh
if is_true $NOBOOTLOADER ; then
LogPrintError "Cannot install secure boot loader (shim) because GRUB2 was not successfully installed"
return 1
fi
-------------------------------------------------------
By accident this skip does not happen
when 670_run_efibootmgr.sh succeeded
because that sets 'NOBOOTLOADER='.
So I think in the end that mess even works
but it clearly needs to be cleaned up...
[Export of Github issue for rear/rear.]