#1257 PR `merged`: Corrected bad test for UEFI partition check inside /boot.¶

Labels: bug, fixed / solved / done

gozora opened issue at 2017-03-21 18:35:¶

Today I've accidentally found a small regression that can basically avoid ReaR to correctly setting USING_UEFI_BOOTLOADER=1.

With old code:

if [[ -n $(find /boot -maxdepth 1 -iname efi -type d) ]]; then
    return    # not found
fi

If efi directory is found inside /boot 320_include_uefi_env.sh would prematurely return.

gdha commented at 2017-03-21 19:57:¶

@gozora To my knowledge this was already fixed - did you forgot a git pull?
See https://github.com/rear/rear/commit/80494f6ade6951fcf690ded54dab0f3835df8e21#diff-be40da13c57e48c9ded13d219b62dff2

gozora commented at 2017-03-22 07:34:¶

Hello @gdha,
My fix is in file 320_include_uefi_env.sh the one you are mentioning is about 310_include_uefi_tools.sh

jsmeix commented at 2017-03-22 10:16:¶

@gozora
many thanks for finding the other faulty test!

Could you - by the way - have a look at my comment
in 310_include_uefi_tools.sh about whether or not it might
be better to abort with a clear Error message instead of
proceeding 'bona fide'?
My blind guess is that when the user has UEFI
those stuff in those scripts must be successfully done
and if that is not possible it should abort with an Error.
In particular because the 'prep' stage is run during
"rear mkrescue/mkbackup" where an Error abort can
tell the user early that something is wrong (in contrast
to an Error abort during "rear recover" where it is usually
too late for the user to get things properly fixed).
But I am not a sufficient UEFI expert to make an educated
decision if an Error abort is better here.

gozora commented at 2017-03-22 11:31:¶

@jsmeix

Could you - by the way - have a look at my comment
in 310_include_uefi_tools.sh about whether or not it might
be better to abort with a clear Error message instead of
proceeding 'bona fide'?
My blind guess is that when the user has UEFI
those stuff in those scripts must be successfully done
and if that is not possible it should abort with an Error.
In particular because the 'prep' stage is run during
"rear mkrescue/mkbackup" where an Error abort can
tell the user early that something is wrong (in contrast
to an Error abort during "rear recover" where it is usually
too late for the user to get things properly fixed).
But I am not a sufficient UEFI expert to make an educated
decision if an Error abort is better here.

Honestly? I really don't know which approach would be better :-(. I'll try to focus on this part of code during my testing and maybe to find out what would be better behavior ...

V.

jsmeix commented at 2017-03-22 12:38:¶

@gozora
I fully agree with you.

First things first.

I will merge it soon because I think since your
https://github.com/rear/rear/pull/1257/commits/42d1c4c5a1fc4019d104b3a87850816d666c1018
what @gdha requested is fulfilled.

jsmeix commented at 2017-03-22 13:39:¶

How unfortunate - now I can no longer merge it ;-)

@gdha
many thanks for your merge!
:-)

[Export of Github issue for rear/rear.]

#1257 PR merged: Corrected bad test for UEFI partition check inside /boot.¶