#2051 PR closed
: 630_run_efibootmgr.sh wrongly checks boot loader outside chroot¶
Labels: fixed / solved / done
, won't fix / can't fix / obsolete
gozora opened issue at 2019-02-20 16:02:¶
-
Type: Bug Fix
-
Impact: Normal
-
Reference to related issue (URL): https://github.com/rear/rear/issues/2035#issuecomment-465602717
-
How was this pull request tested?
Full backup restore on UEFI bootable RHEL 7.6 -
Brief description of the changes in this pull request:
When system is set for UEFI boot, finalize/Linux-i386/630_run_efibootmgr.sh script should create boot menu entry viaefibootmgr
. This however never happens because script is looking for $UEFI_BOOTLOADER outside chroot (/mnt/local) environment, where we unlikely find $UEFI_BOOTLOADER. This leads to messages like shown in https://github.com/rear/rear/issues/2035#issuecomment-465602717 (despite system might still boot without any problem).
This patch changes condition mentioned earlier and looks for $UEFI_BOOTLOADER inside of chrooted environment (/mnt/local).
gozora commented at 2019-02-20 16:05:¶
@jsmeix this looks to be part of
e3ca4ce8987dcd475696f32ce49ea3b0bc3dbb2a "Blind attempt to clean up
630_run_efibootmgr.sh", I guess we need to check for $UEFI_BOOTLOADER
inside /mnt/local shouldn't we ?
Or was there some other intention I've missed ?
V.
jsmeix commented at 2019-02-20 16:58:¶
@gozora
thank you for this possible fix.
I like to see the "rear -D recover" log to see what actually goes on,
cf.
https://github.com/rear/rear/issues/2035#issuecomment-465663479
I think this pull request conflicts with my
https://github.com/rear/rear/pull/2047
because therein I renamed/renumbered
usr/share/rear/finalize/Linux-i386/630_run_efibootmgr.sh
into usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
gozora commented at 2019-02-20 18:10:¶
@jsmeix
I think this pull request conflicts with my
#2047
because therein I renamed/renumbered
usr/share/rear/finalize/Linux-i386/630_run_efibootmgr.sh
into usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
You are right! I did not realized the #2047 is not yet merged. But I somehow have a feeling that Git will handle this correctly, if not I can fix this PR ...
V.
gozora commented at 2019-02-21 09:25:¶
@jsmeix seeing your commit https://github.com/rear/rear/pull/2047/commits/1bba7ff1b832849108ac6a92d313739235727821, I guess we can close #2051 ...
jsmeix commented at 2019-02-21 09:28:¶
I fixed it in
https://github.com/rear/rear/pull/2047
via
https://github.com/rear/rear/pull/2047/commits/1bba7ff1b832849108ac6a92d313739235727821
with an explanatory comment so that this pull request
is now obsolete.
@gozora
many thanks for your analysis what went wrong and your fix!
[Export of Github issue for rear/rear.]