U-Boot gpt verify: Know Which Fields the Layout Check Actually Compares

A manufacturing script may treat a successful gpt verify
as proof that storage matches an entire partition specification. In
U-Boot v2025.01, that conclusion is broader than the implementation. The
command checks useful properties, but several supplied fields are not
comparison criteria. For a Buildroot product that packages this
bootloader, define the acceptance contract from the tagged
implementation before relying on its return value.

Separate the
basic check from the pattern check

The command accepts an optional partition string. Without one,
gpt_verify() takes a basic-check path. With a successfully
parsed string, it calls gpt_verify_partitions() with the
expected entries and their count. Parsing a field does not mean that the
verifier later compares it. In particular, the parsed disk GUID is freed
after verification; it is not passed as a disk-identity comparison
argument. Command
reference, command
implementation.

Both paths use gpt_verify_headers(). It validates the
primary GPT, requires its alternate-header location to point to the last
block, then validates the backup GPT there. The lower-level checks
include the header and entry-array CRCs. These detect certain structural
or integrity problems; they do not authenticate partition contents. Tagged
GPT implementation.

There is a further boundary: the two copies are validated
individually. This function does not compare their entry arrays for
equality. After the backup check, the returned header and entries are
the backup copy, which the partition-pattern loop then examines. Two
individually valid copies should not be assumed equivalent solely
because this call succeeded.

Read the comparison loop
as a contract

For each supplied expected partition, the loop compares the name and
the size in blocks. It compares the start block only when the expected
start value is nonzero. It does not compare the expected disk GUID,
partition UUID, partition type GUID or partition attributes in this
loop. Supplying those fields in a layout string therefore does not turn
this command into an identity or attribute verifier.

The loop stops after the number of expected entries. It does not then
establish that no further populated entries exist. A specification
describing a matching prefix is a weaker assertion than a complete
inventory comparison. If a product forbids extra partitions, add an
explicit entry-inventory check rather than inferring it from
success.

The final extend-to-end partition deserves special attention. The
parsed zero-size representation permits a size mismatch for the last
expected entry. In that branch, continue advances the loop
immediately, before the optional start comparison. Thus the exemption
can skip both size and start verification for that entry. This is a
source-derived observation about v2025.01, not a promise for other
releases. Comparison
loop.

Turn the gaps into targeted
checks

For a fixed-layout product, express the expected start and length
explicitly wherever they are fixed. If the final partition genuinely
expands with device capacity, calculate and inspect its actual start and
end separately. Do not use an extendable-size declaration as evidence
that its start was checked.

Maintain distinct assertions for properties the command does not
cover: the complete partition inventory, required GUIDs and attributes,
agreement between primary and backup representations, and the payload
stored in each region. A filesystem image in the wrong partition can
coexist with perfectly valid GPT metadata. Likewise, a correct partition
name and extent do not certify the root identifier consumed later by
Linux.

A useful proposed qualification matrix changes one property at a time
in disposable disk images. Include a renamed partition, wrong fixed
size, wrong nonzero fixed start, a GUID-only change, an extra populated
entry and a changed start on an extendable final partition. Keep GPT
CRCs valid for semantic mutations; otherwise the basic integrity check
can fail before the comparison under investigation is reached.

For each fixture, predict which check should reject it and record the
actual command status separately from the broader product verdict. If a
field is outside this verifier’s scope, acceptance must come from
another check. These fixtures were not executed for this article, and no
production storage was modified. The outcome sought is a precise
partition-layout gate, not a larger meaning assigned to one successful
command.