Hi Jan, > 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?
it looks fishy because it's not so obvious what's actually going on. It took me a while to understand the "grand scheme of things", so here is a brief summary: 1. `check_GPT_FAT_entry` does more than just checking the FAT entry, it actually writes a string (fatXX) to one of its arguments (pfst->name) if it was able to determine the FAT partition type. 2. The return value of `check_GPT_FAT_entry` is a boolean indicating success. If the return value is false (i.e. error), then `dev->part_list` is set to NULL. The consequence is that *every* partition of the underlying device is skipped. In other words, a single bad partition results in the whole device being ignored. 3. Whether we probe (i.e. mount) a partition and check for BGENV.DAT depends on the string value pfst->name which is written in step 1), see `probe_config_partitions`. Kind Regards, Michael -- Michael Adler Siemens AG Technology Connectivity & Edge Smart Embedded Systems T CED SES-DE Otto-Hahn-Ring 6 81739 Munich, Germany Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 -- 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/d255cu6chxp7ka7htcxlyhwufkuqzdnmveob5z7lb4rxb2ti3g%40lnp3mmws2hv3.
