[0cwa]

Purpose

Prepare a baseline-first, fail-closed LineageOS pdx235 vold timeout replacement. The production exFAT patch must NOT be applied until an unmodified vold has been built by CI and proven byte-for-byte identical to the executable in the publisher-authenticated LineageOS source OTA.

Gate 0 — reproduce the unmodified original (NOT YET COMPLETED)

• Source is the exact 2026-10-16 LineageOS 24.0 pdx235 signed OTA, independently pinned SHA-256 8af46661a1440e98018bb2abb155317d6d4ae54e051160f0786b75c1e6806c82, recovered from successful verified production runs #39632433468 and #39678546023.
• src/ci/resolve_lineage_vold_ota.py prefers the exact official builds-API record and refuses a conflicting digest. A missing historical API entry can fall back only to the immutable original official archive URL/digest pin.
• src/ci/prepare_lineage_vold_reference.sh checks the downloaded ZIP SHA-256, independent official LineageOS publisher key, and whole-OTA signature using avbroot ota verify, then extracts the original /system/bin/vold as read-only reference bytes.
• src/ci/build_lineage_vold.py baseline syncs/verifies the full pinned 1,243-project source tree and builds the unmodified daemon without even opening/applying the timeout patch. It compares all binary bytes, records exact SHA-256 hashes/ELF identities/sizes/first differing offset, and fails closed on any difference.
• The heavy, nonpublishing CI job lineage_vold_exact_baseline is opt-in only on this owned review branch, has contents: read, uploads just baseline-report.json, and does not build or publish a modified OTA. It needs an isolated [self-hosted, linux, x64, modos-lineage-large] runner with Android build prerequisites and at least 220 GB free scratch. Set MODOS_LINEAGE_LARGE_SCRATCH and MODOS_VOLD_BASELINE_RUNNER_READY=true repository variables after provisioning.
• Lightweight CI tests are synthetic, not proof of real reproducibility. Until the large runner actually produces a successful byte_identical: true report for the genuine OTA, this gate remains blocked.

Gate 1 — only after Gate 0: timeout patch (NOT ENABLED)

• The existing two-line source change raises only exFAT fsck from 45 to 120 seconds.
• The patched build command now requires --baseline-report, --baseline-binary, and --reference-vold, and independently rechecks exact bytes/source identity before applying the patch. It is NOT part of the baseline CI job.
• Target scope is exclusively LineageOS 24.0 pdx235; ro.lineage.* properties are checked in the product partition and original executable ownership, SELinux xattr and filesystem metadata must survive injection.

Gate 2 — unpublished OTA + device acceptance (NOT COMPLETED)

Require reviewed patched artifact provenance, authenticated OTA postflight and nonpublishing rootless/Magisk builds. Independently test device boot, FBE/storage mounting, and exFAT behavior before any production use. Each newer nightly requires a fresh exact baseline and patch qualification.

Gate 3 — staging/publication (NOT AUTHORIZED)

The binary and staging provenance digest-approval fields in locks/lineage-vold-exfat-timeout.json remain blank. The scheduled and manual module selectors are wired but default off. Published use fails closed until the exact reviewed binary/staging provenance SHA-256s are pinned. GrapheneOS is explicitly excluded. Do not merge, select it in production, or force-publish merely because ordinary CI passed.

Documentation: docs/lineage-vold-exfat-timeout.md.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[0cwa]

Merge hold (owner request, 2026-10-21): Keep this vold exFAT timeout change out of main for now. This PR is intentionally in draft and must not be enabled in GrapheneOS builds or scheduled/release selections. Treat any future merge as a separate, explicit review/approval decision. The GrapheneOS fsck/SELinux isolation guard is handled independently in #160.

[0cwa]

Vold module review — deployment not yet ready (2026-10-21)

The isolated upstream change is sensible: on the pinned LineageOS android_system_vold revision, only the exFAT fsck timeout moves from 45s to 120s. The draft provides useful source/manifest pins, AArch64 ELF and dependency checks, a strict target-build check, and an existing-file/SELinux-label preservation check. The original PR CI passed.

I made two small commits to this draft to prevent unintended release churn when the module is off: the existing selection fingerprint bytes are retained until vold is selected, and tests/rom_contract_test.sh now covers both the disabled serialization and enabled digest fields. Updated CI is running.

Blockers before merge + scheduled enablement + force-publish:

1. No real binary/OTA qualification. The documented full 1,243-project source sync and m vold were not executed, and this PR ships no validated vold + provenance.json. Synthetic ELF/manifest contract tests cannot establish boot safety, Android linker compatibility, fsck behavior on hardware, or successful encrypted-data mounting. Build from the pinned full source tree, verify artifact and OTA injection against authentic 20261016 pdx235 images, and require device-side boot/functional validation before publishing a system-critical vold replacement.
2. No scheduled workflow path. release-lineage.yml, build-rom.yml, and load_schedule_definition.sh currently provide no lineage-vold-exfat-timeout selector pass-through, artifact download/build step, or trusted artifact provenance delivery. Adding a TOML default alone would be silently ignored or fail. The scheduled pair-preflight must see the same authenticated binary before computing selection fingerprints as the build job sees.
3. Pinned to one nightly. The adapter explicitly accepts only lineage-24.0-20261016-nightly-pdx235-signed. A rolling scheduled job must provision, rebuild/requalify and re-pin for every newer source OTA, or intentionally fail closed; never substitute this 20261016 binary into a later nightly.
4. Publishing is not a CI substitute. Keep release defaults off, avoid GrapheneOS integration, ensure any source/publication provenance requirements are met, and only then run a one-off force-publish and verify the resulting rootless/magisk OTA pair plus install/boot and update delivery.

Current decision: retain draft status; do not merge, enable scheduled production builds, or publish an untested vold binary. This does not negate the owner's new conditional merge authorization: it documents the remaining conditions for readiness.

[0cwa]

Baseline-first CI progress (2026-10-22 UTC)

The ordering is now enforced in code: build_lineage_vold.py baseline never opens or applies the timeout patch, and records a diagnostic JSON receipt only after building unmodified vold; it fails unless every byte matches the authenticated source OTA reference. The patched build subcommand requires a baseline report, original OTA vold and unmodified binary and re-verifies their full byte identity before git apply.

Historical source identity is now pinned to the SHA-256 8af46661a1440e98018bb2abb155317d6d4ae54e051160f0786b75c1e6806c82 and the official LineageOS archive URL, grounded in verified ModOS runs #39632433468 and #39678546023. Actual OTA bytes must still pass that digest, the independent signer-key pin and avbroot ota verify before being used as reference.

CI: #39697359803 passed the complete normal test job at exact PR head 0038a55ee13082684ff539d34fdbbe40e8baeab8; the added reproduction tests are synthetic. The large lineage_vold_exact_baseline job is SKIPPED by design, not a successful physical Android build. It requires a trusted [self-hosted, linux, x64, modos-lineage-large] runner with Android build tools and ≥220 GB free scratch, and repository variables MODOS_LINEAGE_LARGE_SCRATCH and MODOS_VOLD_BASELINE_RUNNER_READY=true. No such execution has occurred.

The rollout remains draft and unmerged; both LineageOS and GrapheneOS production defaults remain off for this module, the approved patched binary hash/staging tag remain blank, and no OTA release or force-publish was dispatched. Next gate is to provision that runner and obtain a real byte_identical: true report. If it differs, investigate the exact build environment/source/toolchain before touching the patch or publishing any candidate.

[0cwa]

Stage-1 baseline prerequisite merged — 2026-10-22

The independent, unmodified-vold-only infrastructure has been merged to main as #161 (merge 986e238e2b5075899519fd9035b60826a3c690f2; passing PR CI).

• New manual, nonpublishing workflow: .github/workflows/vold-baseline.yml.
• Complete official 1,243-project manifest and pinned 2026-10-16 source digest retained on main; no daemon patch/injection code included.
• Reference obtained only from the SHA-256/publisher-verified original OTA; clean unmodified build must be byte-for-byte identical and produces only a diagnostic baseline-report.json.
• A real run still needs a trusted modos-lineage-large self-hosted runner with >=250 GB free and repository variables MODOS_LINEAGE_LARGE_SCRATCH and MODOS_VOLD_BASELINE_RUNNER_READY=true. No real baseline proof exists yet.

Retain this #157 draft unmerged. Do not enable the scheduled selector or force-publish a replacement vold until the merged baseline workflow produces a reviewed actual byte_identical: true artifact, followed by separate patched binary/OTA/device qualification. The previous ordinary CI unit-test successes do not satisfy this first gate.

See stage-1 runner setup and acceptance.

[0cwa]

2026-10-22 — Build-scope correction / dependency feasibility finding

The baseline workflow already invokes m vold, which builds the vold target and its required build dependencies, not the entire LineageOS firmware. The main inefficiency is that src/ci/build_original_vold.py sync currently checks out every project in the 1,243-project pinned manifest. Google's repo sync <project>... supports restricting checkout to selected paths; a smaller immutable source set should be investigated, while continuing to require byte-for-byte equality with the authenticated OTA executable.

Additional reproducibility blocker: the pinned LineageOS/android_device_sony_pdx235 tree at 0559de69466e1e9af69b121985f592c4f4609283 has

• device.mk → $(call inherit-product, vendor/sony/pdx235/pdx235-vendor.mk)
• BoardConfig.mk → include vendor/sony/pdx235/BoardConfigVendor.mk
• extract-files.py → extracts proprietary Sony blobs via the LineageOS extract-utils and vendor/sony/sm6375-common.

Neither vendor/sony/pdx235 nor vendor/sony/sm6375-common is present as a source project in the pinned official manifest. Therefore even the 1,243-project public checkout alone may be insufficient to configure lineage_pdx235-userdebug and reproduce official vold. The exact vendor build inputs must be obtained/derived with verifiable provenance or an explicitly reviewed build-configuration alternative; do not silently ignore missing product dependencies.

Review the exact vold Android.bp at the pinned revision: vold links substantial platform libraries (libfs_mgr, libavb, libbinder, etc.) and declares other required build modules. A standalone C++ compile is not expected to reproduce the signed OTA executable.

The manual baseline run #39699955476 did not reach compilation: BASELINE_READY and SCRATCH were both empty. The 250 GB check is a conservative limit for the current all-project checkout, not a measured minimum required to build the vold module.

Suggested safe next engineering sequence: (1) audit/recover/pin the vendor configuration and its provenance; (2) create a separate read-only, nonpublishing, bounded repo sync <paths>... experiment with explicitly pinned source/toolchain dependencies; (3) build only m vold; (4) compare all resulting bytes with the exact authenticated OTA executable. If subset builds fail, expand the pinned dependency list rather than using SOONG_ALLOW_MISSING_DEPENDENCIES or altering the acceptance gate. Keep this PR draft, scheduled module selection off, and force-publish blocked until a real binary comparison is accepted.