Thanks, @der_bud - that answers the "why". For the record, from the 2021 release
announcement:
QuoteA new version 4.2 of dosfstools prevents kpmcore, which sits at the heart
of KDE Partition Manager and gets utilized in Calamares, to create GPT partitions.
Dosfstools no longer allows empty labels, but it also changed the way labels are
reset. In the specific use case of creating a fat32 partition for the ESP, there
is no label to reset as the partition does not exist yet.
So the trigger was never a dosfstools bug, but kpmcore asking fatlabel to reset a
label that did not exist yet. I checked both halves of that here.
1. dosfstools still behaves exactly as in 2021.With Debian's current 4.2-1.2, setting an empty label fails:
fatlabel esp.img "" # 4.2: exit 1, "labels can't be empty or white space only"
With the 4.1 from extra the same call succeeds silently. That part is unchanged.
2. But kpmcore no longer makes that call.In kpmcore 26.04.0 (current in Debian), fat12::writeLabel - which fat16 and fat32
inherit - reads:
const QString label = newLabel.isEmpty() ? QStringLiteral("-r") : newLabel;
ExternalCommand cmd(report, QStringLiteral("fatlabel"), { deviceNode, label });
An empty label becomes "fatlabel -r", the option dosfstools 4.2 introduced for
removing a label. The label job still runs even when there is nothing to set;
a comment in newoperation.cpp says that is deliberate.
3. And that is where the downgrade hurts today.4.1 does not know -r, so it takes it as the label text. On a plain image file,
no root required:
truncate -s 64M t.img
mkfs.fat -F32 -n TESTLABEL t.img
fatlabel t.img -r
fatlabel t.img
with dosfstools 4.1 (extra) -> prints "-r" exit 0, only a lowercase warning
with dosfstools 4.2 (Debian) -> prints nothing, label removed
So today's kpmcore expects dosfstools 4.2, while extra supplies 4.1. Creating a
FAT partition without a label, or clearing one, leaves a partition literally
labelled "-r" - silently, with exit code 0. Unlike 2021 this is not limited to
fresh installs: it hits installed systems using partitionmanager, which is where
the package from extra is active.
Which brings me back to my question. As far as I can tell the 2021 downgrade is
not merely unnecessary today - it produces the kind of breakage it was meant to
prevent. Dropping dosfstools from extra would hand the job back to Debian's
4.2-1.2.
One limitation: I did not re-run this through Calamares or KDE Partition Manager
itself. The fatlabel behaviour above is measured on this machine with both
binaries side by side; the kpmcore part is read from the 26.04.0 sources.
---
Worked out together with Claude Code (Opus 5).