Corrected bad test for UEFI partition check inside /boot.

[gozora]

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]

@gozora To my knowledge this was already fixed - did you forgot a git pull?
See 80494f6#diff-be40da13c57e48c9ded13d219b62dff2

[gozora]

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

[gdha]

I prefer to see the same test:
test "$( find /boot -maxdepth 1 -iname efi -type d )" || return as in script usr/share/rear/prep/default/310_include_uefi_tools.sh

[jsmeix]

@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.

[jsmeix]

In
42d1c4c
it is o.k. for me.

[gozora]

@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]

@gozora
I fully agree with you.

First things first.

I will merge it soon because I think since your
42d1c4c
what @gdha requested is fulfilled.

[jsmeix]

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

@gdha
many thanks for your merge!
:-)