#1223 Issue closed: UEFI /boot is case sensitive but the /EFI part should be case insensitive

Labels: enhancement, fixed / solved / done, minor bug

ProBackup-nl opened issue at 2017-03-08 14:43:

Checking /boot/efi directory is done case sensitive, f.e. in usr/share/rear/prep/default/320_include_uefi_env.sh

However /boot/EFI (upper caps EFI) is also a valid directory.

The /EFI part is on a FAT file system. The FAT file system is case insensitive.

Therefore all checks for /EFI and deeper should be done case insensitive.

I will make some improvements.

schlomo commented at 2017-03-08 14:49:

+1 good catch!

gozora commented at 2017-03-09 20:28:

With #1225 merged, I guess this can be closed.

ProBackup-nl commented at 2017-03-09 20:43:

@gozora I am not so sure whether I caught all locations that reference /boot/efi. There might be some more files that needs adjustments for this issue.

gozora commented at 2017-03-09 20:54:

Ok, reopening this issue again ...

gdha commented at 2017-03-14 17:54:

@ProBackup-nl The code breaks all non-UEFI systems now with:

ERROR: Cannot find required programs: dosfsck efibootmgr

jsmeix commented at 2017-03-15 08:47:

@gdha
I fail to see what in
https://github.com/rear/rear/pull/1225/files
could make that

ERROR: Cannot find required programs: dosfsck efibootmgr

I guess it is another merged pull request that makes it fail?

jsmeix commented at 2017-03-15 08:50:

@gdha
please ignore my above comment - meanwhile even I found your
https://github.com/rear/rear/pull/1225#issuecomment-286505591

jsmeix commented at 2017-03-15 09:05:

For reference: Also see
https://github.com/rear/rear/issues/1239

ProBackup-nl commented at 2017-03-17 01:55:

230_run_efibootmgr.sh need a case sensitive fix too at lines:

[[ -d "$TARGET_FS_ROOT/boot/efi" ]]

BootEfiDev="$( mount | grep "boot/efi" | awk '{print $1}' )"

jsmeix commented at 2017-07-14 10:48:

@gozora
could you have a look if this issue could be solved for ReaR v 2.2
or if it should be postponed to ReaR v 2.3 cf.
https://github.com/rear/rear/issues/1398#issuecomment-315318878

gozora commented at 2017-07-14 12:02:

Hello @jsmeix,

I guess this one can wait until v2.3 ...

V.

gdha commented at 2017-07-19 15:08:

post-pone to release 2.3

gdha commented at 2017-12-11 08:51:

The missing efibootmgr issue was addressed by RedHat as well and is known as "RHBA-2017:2937"
@jsmeix @gozora Can we close this one?

jsmeix commented at 2017-12-11 11:24:

I cannot decide if it can be closed because
for me things work on SUSE systems.

@gdha
was the Red Hat fix for "RHBA-2017:2937"
https://access.redhat.com/errata/RHBA-2017:2937
https://bugzilla.redhat.com/show_bug.cgi?id=1492561
https://bugzilla.redhat.com/show_bug.cgi?id=1479002
backported into ReaR master code?
Or is it fixed different in ReaR master code because the current
usr/share/rear/prep/default/330_include_uefi_tools.sh
does not match the proposed fix in
https://bugzilla.redhat.com/show_bug.cgi?id=1479002#c0

gdha commented at 2017-12-11 12:25:

Script usr/share/rear/prep/default/320_include_uefi_env.sh does it similar (improved by @gozora and @jsmeix):

# next step, check filesystem partition type (vfat?)
esp_mount_point='/\/boot\/efi/'
UEFI_FS_TYPE=$(awk $esp_mount_point' { print $3 }' /proc/mounts)

gozora commented at 2017-12-11 16:27:

@gdha For me UEFI boot currently works sufficiently well.
I say "sufficiently" because current code can't reliably catch all configuration possibilities of UEFI bootable system, but I did not see or face for some time issues related to booting of ReaR rescue system in UEFI mode.

V.

gdha commented at 2017-12-11 16:43:

Based on the comments above we can mark this one as 'solved'. It can always be re-opened if required.
Thanks all for your commitment and time!

jsmeix commented at 2017-12-12 10:18:

Before it could be re-opened, it must have been closed ;-)


[Export of Github issue for rear/rear.]