# Pastebin 5ZyE56im
It appears that the "boot flag" in the EFI partition table, as it's represented in tools like gparted, might be considered deprecated or, more accurately, a simplification of the underlying mechanism.

Here's a breakdown of why:

GPT and GUIDs: The GPT (GUID Partition Table) scheme, used by EFI systems, relies on GUIDs (Globally Unique Identifiers) to identify partition types. There's no dedicated "boot flag" in the GPT specification itself.
EFI System Partition (ESP): The partition from which an EFI system boots is identified by a specific GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B. This GUID designates the partition as an ESP.1   
1.
GUID Partition Table - Wikipedia

en.wikipedia.org

gparted's "Boot Flag": Tools like gparted provide a user-friendly way to manage partitions. They might use the term "boot flag" to simplify the process of marking a partition as bootable. When you set the "boot flag" in gparted for an EFI partition, it's essentially setting the partition's type GUID to the ESP GUID.
Deprecation in kpm core: According to the search results, the "ESP flag" in kpm core (a partitioning tool) has been deprecated. This suggests a move away from using a separate flag and relying solely on the partition type GUID for ESP identification.
In essence:

The concept of a "boot flag" in the EFI context is more of an abstraction provided by partitioning tools.
The actual mechanism for identifying a bootable EFI partition is the ESP GUID.
While some tools might still use the term "boot flag," the underlying implementation likely involves setting the partition type GUID.
Key Takeaways:

When working with EFI systems, focus on the partition type GUID to determine if it's an ESP.
Tools like gparted can simplify partition management, but it's important to understand the underlying mechanisms.
The trend seems to be moving away from using separate flags and relying on GUIDs for partition identification.