U-Boot Extlinux APPEND: Trace Replacement, Expansion and Retained bootargs

An extlinux entry contains a short command line, yet Linux receives
duplicated parameters or values left over from an earlier boot attempt.
The word APPEND can encourage the wrong mental model:
U-Boot does not simply concatenate that text onto the existing
bootargs variable in every case.

The relevant path here is U-Boot v2025.01’s shared PXE/extlinux label
handling and FDT handoff. For a Buildroot product using this path, the
review needs the selected label, current environment and final working
tree. Other boot methods and board overrides can construct arguments
differently.

APPEND normally
replaces the environment value

In label_boot(),
U-Boot creates a temporary command-line buffer when the label has append
text or the relevant ipappend bits are set. It copies the
label text, adds requested network fragments, expands environment
references and calls
env_set("bootargs", finalbootargs).

The previous value is not automatically prepended. It participates if
the label explicitly references it, for example through
${bootargs}. That distinction changes how repeated attempts
behave.

Consider this hypothetical string exercise. The initial value is
root=PARTUUID=A, and the label text is
${bootargs} quiet. The first expansion produces
root=PARTUUID=A quiet. If the same label is attempted again
with that environment value still present, another quiet is
added. The growth comes from feeding the previous output back as an
input, not from an unconditional append operation inside
env_set().

A cleaner design uses a separate, release-owned base variable when
composition is needed. The output variable should not double as the
immutable source unless repeated accumulation is explicitly
intended.

A missing APPEND
can preserve earlier state

If neither append text nor the relevant ipappend bits
trigger that block, it does not rewrite bootargs. A second
label can therefore inherit a value established by an earlier attempt in
the same session. Other code may still modify it later, so this is a
local branch observation rather than a claim about every final Linux
command line.

Test label transitions, not just fresh resets. Compare a label with
explicit arguments followed by one without them, and compare a label
referencing ${bootargs} with one referencing a separate
base value. The expected result should be an exact string, including
ordering and whitespace, before any kernel-specific interpretation.

The length check
happens before expansion

The same code checks the combined lengths of literal append text and
generated network fragments against CONFIG_SYS_CBSIZE. That
check precedes environment expansion. A short reference can expand into
a much larger value.

The macro-expansion
helper limits its output and returns -ENOSPC when
capacity is exhausted. This label_boot() call does not
inspect that return value before setting bootargs.
Consequently, passing the literal-length check is not proof that the
expanded string remained complete.

For a bounded test, use a long harmless environment value near the
configured capacity and inspect the resulting string without starting an
OS. Include an undefined variable: the helper copies no value for an
absent environment entry. These cases target expansion behavior directly
and avoid attributing a shortened command line to the Linux parser.

Inspect the tree that
reaches the kernel

The later fdt_chosen()
implementation calls board_fdt_chosen_bootargs(). Its
weak default returns the environment’s bootargs; a non-null
result is written to /chosen/bootargs. A board override can
supply a different string. If the hook returns null, this code does not
replace an existing property.

Capture both the environment result after label processing and the
working-tree property at the actual handoff boundary. A discrepancy then
points to a specific later producer instead of prompting another edit to
the extlinux file.

Duplicate parameters need parameter-specific interpretation in Linux.
Do not adopt a universal “last value wins” rule or remove every
repetition mechanically; some options legitimately accept multiple
instances. This article resolves the construction path, not each kernel
option’s semantics.

The most useful regression cases are therefore explicit replacement,
repeated self-reference, an absent APPEND after a previous label,
expansion near capacity and a board hook that changes the final
property. No commands were executed here. These source-derived cases
expose stateful argument construction without confusing it with
image-signature policy or kernel parsing.