Two field units got no fingerprint sensor from fingerprintd 0.2.3's
manifest: its focal64 line pinned the sha256 of one Android build's
trustlet (16.82.0, the dev phone's), and Fairphone re-signs that trustlet
every release, so the pin matches exactly one of the six builds seen. A
user on 16.100.0 had to edit the manifest by hand; another ended up with
a file QTEE refuses.
The extractor now tries the active slot's partitions first
(androidboot.slot_suffix from the kernel command line): for a signed
image only the running TZ's own slot is guaranteed to load. An mbn line
may give '-' instead of a hash, which means structural verification
only: ELF64 header, every segment present at the size its program header
declares, page-aligned offsets, a sane total. The loader in TZ verifies
the signature and the per-segment hashes itself and refuses a damaged or
foreign image (one flipped byte -> ERROR_ELF_SIGNATURE_ERROR, measured),
so the whole-image hash added fragility and no protection. A real sha256
is still honoured, and the sha256 of what was installed is logged either
way.
--refresh re-derives mbn dests even when a file exists, replacing it
only with an image that verifies; consumers call it from
post-install/post-upgrade so a fresh 'apk add' needs no reboot and a
hand-placed or wrongly pinned trustlet is replaced on the next upgrade.
Verified on the dev phone (busybox): malformed inputs are refused with a
reason (missing, truncated or oversize segment; non-ELF, ELF32 or short
mdt; a garbage offset), both slots reassemble to the known-good hash, a
foreign file survives a plain run and is replaced by --refresh, a failed
refresh keeps the old file, pins still work, and the real post-upgrade
path re-derived the installed trustlet with the daemon restarting on it.
Record: fp6 repo journal/blobs/ and journal/fingerprint/, 2026-09-11.
CI run 52 failed at minute 57 with `fp6-vendor-blobs-extract: FAILED` from
abuild's checksum verification: 9575e55 changed the extractor and left its
sha512sums entry alone. Nothing was installed or published; latest is the
run-51 image.
Fix the sum, and stop paying an hour to learn it. check-aports.sh sources
every APKBUILD under aports/ and compares the committed sha512sums of its
local source files (scripts, units, configs, patches, including ones in a
subdirectory) against the files themselves. build.sh runs it before
pmbootstrap touches anything, so this class of mistake now fails in the first
seconds of a run and prints the line to paste. Aports whose sums build.sh
regenerates with pmbootstrap checksum are read from build.sh and skipped, so
the two lists cannot drift.
Verified: the checker reports exactly the run-52 mismatch on the tree as
pushed and nothing on the tree as fixed; a scratch copy with one corrupted
sum is caught; the fixed aport builds under abuild in an alpine:edge
container (the only complaint was the throwaway signing key at the index
step, which the CI's pmbootstrap flow does not have).
The fingerprint matcher is a proprietary OEM-signed trustlet, and it is not
shipped as one file: QTEE images live in the modem partition's image/ as an
ELF header+hashes file plus one payload per program header, and the loader
wants each payload written back at its segment's p_offset. So the existing
file directive cannot reach it.
An mbn directive does, with the same guarantees file has: the sha256 is of
the reassembled image, a mismatch tries the next partition, and an unverified
image is never installed. Reassembly is not a concatenation -- segments are
page aligned but not contiguous, gaps stay zero, and two pairs of focal64's
nine segments share an offset, so they are written in index order and the
later one wins, exactly as the bring-up repo's reassemble.py does.
Verified on the dev phone against the hash QTEE has actually accepted since
August: 3600472 bytes, sha256 1930c490..., reassembled from the phone's own
modem_a. The retry path was verified too, with a deliberately wrong first
partition -- which is how the variable clobber got caught: POSIX sh has no
locals, and reassemble() taking rdir= rewrote its caller's copy to the mount
path, so the second partition would have been searched at $MNT/$MNT/...
The fast path needed teaching as well: mbn's dest is the fifth field, and a
first boot would otherwise have exited early and extracted nothing.
Not pushed. The consumer fragment lives in the fingerprintd package.
The preset fix (6ecc1dc) makes the unit run, but multi-user is too late: the
sound card probes at ~21 s, hard-fails (-2, no retry) on the missing ACF, and
the extractor's amp rebind at ~60 s cannot re-form a card whose machine
driver already failed. Re-probing the machine driver does re-form it, but a
late-formed card has a dead capture path - the wcd9378 TX sequencer refuses
PS0 (act_ps 0x3) until the next boot. So rebinding after the fact can never
fully win; extraction has to happen before the drivers probe.
- fp6-vendor-blobs.service: DefaultDependencies=no, run after remount-fs and
before systemd-udev-trigger, so blobs exist before module coldplug.
multi-user stays a second Wants as a post-udev retry if the early run
failed (by-partlabel/make-dynpart-mappings fallbacks need udev).
- aw88261-acf.manifest: add 'rebind platform sound' so the fallback path at
least recovers playback the same boot (capture then heals on reboot).
- fp6-vendor-blobs.post-upgrade (pkgrel 1): systemctl preset + immediate
extract, so installs of the 2026-08-24 image (unit shipped disabled, no
version bump to deliver the preset) finally heal via plain apk upgrade.
- soc-fairphone-fp6-audio pkgrel 1: carries the manifest change.
Verified on the dev phone with the exact staged bytes (sha256-compared):
simulated fresh install (ACF removed, reboot) extracts at 13.3 s, coldplug
probes the amps at 15.1 s, card init at 20.9 s loads the ACF cleanly, and a
1 kHz speaker-to-mic loopback passes on that same first boot with zero TX
sequencer warnings; next boot takes the all-dests-present fast path in 25 ms.
Evidence: fp6 repo journal/blobs/, 2026-08-29.
Assisted-by: Claude:claude-fable-5
The package installs a multi-user.target.wants symlink, but that alone does
not survive image build: pmbootstrap runs systemctl preset-all, which removes
manually-installed .wants links for any unit whose preset does not enable it.
The 2026-08-24 image therefore shipped the service as
'disabled; preset: disabled' and it never ran, so aw88261_acf.bin was never
extracted from the stock vendor partition and a fresh install came up with no
sound card at all.
Reproduced and verified on the dev phone: with no preset file installed,
systemctl preset leaves the unit disabled; with it, the unit comes back enabled
and stays enabled across a full preset-all.
Investigation and evidence: fp6 repo journal/blobs/, 2026-08-28.
Assisted-by: Claude:claude-fable-5
New package fp6-vendor-blobs: a manifest-driven systemd oneshot that
copies proprietary blobs out of the stock Android partitions on first
boot. pmOS installs flash only boot+userdata, so every installed unit
still carries the stock vendor/dsp partitions - the device duplicates a
file it already contains, for its own operation, and nothing proprietary
is distributed by us. Partitions are mounted read-only (ext4 additionally
with noload - not even a journal replay touches the stock data), every
copy is sha256-pinned and a miss fails loudly, and the consuming devices
are unbound and re-probed afterwards so the feature works the same boot.
The rebind is unconditional by design: aw88261 binds on a bare i2c
chip-id probe and requests the ACF only at ASoC card init (~21 s, after
SoundWire enumeration), so a bound device can still be one that lost the
firmware race - and that failed request is never retried.
soc-fairphone-fp6-audio (pkgver 4) stops shipping the blob, installs the
manifest fragment instead, and re-runs the extractor from
post-install/post-upgrade so upgrades restore the file immediately (the
old package version removed it on upgrade). License drops back to plain
BSD-3-Clause - nothing proprietary left in the package.
Verified on the dev phone (fp6 repo journal/blobs/captures/
2026-08-24-first-boot-extractor-verification.txt): first-boot extraction
+ same-boot audio, mid-session post-upgrade recovery, and the everyday
fast-path no-op; committed files byte-identical to the tested deployment.
Assisted-by: Claude:claude-fable-5
