On 17.10.23 17:42, 'Michael Adler' via EFI Boot Guard wrote:
> This fixes a regression introduced in commit b23816ab9626 which results
> in efibootguard skipping the config file probing of the whole device if
> it encounters some partition for which it could not determine the FAT
> bit size.
>
> Details:
>
> The expected behavior of the `check_GPT_FAT_entry` function is to return
> false if (and only if!) an actual error occurs. Being unable to
> determine the FAT bit size must not be considered an error. The solution
> is to return true in this case as well.
>
This looks fishy: We are now adding a partition in read_GPT_entries to
the list which is NOT a FAT partition. Why should that be correct?
Jan
> Fixes: b23816ab9626 ("fix: correctly calculate FAT bit size based on cluster
> count")
> Reported-by: Felix Moessbauer <[email protected]>
> Signed-off-by: Michael Adler <[email protected]>
> ---
> tools/ebgpart.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/ebgpart.c b/tools/ebgpart.c
> index 6f60c24..b168903 100644
> --- a/tools/ebgpart.c
> +++ b/tools/ebgpart.c
> @@ -121,7 +121,7 @@ static bool check_GPT_FAT_entry(int fd, struct
> EFIpartitionentry *e,
> int fat_bits = determine_FAT_bits(&header);
> if (fat_bits <= 0) {
> /* not a FAT header */
> - return false;
> + return true;
> }
> if (asprintf(&pfst->name, "fat%d", fat_bits) == -1) {
> VERBOSE(stderr,
--
Siemens AG, Technology
Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "EFI
Boot Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/d8a392e9-ee00-467e-a1dd-ccba97bffc4a%40siemens.com.
