TeslaUSB Enhanced v1.2.0-rc.5

TeslaUSB Enhanced v1.2.0-rc.5

This is the official Latest release of the TeslaUSB Enhanced project for
the Raspberry Pi Zero 2 W. The existing rc.5 build has been promoted to a full
release without changing its image, source tag, download names, or checksums.
The rc.5 identifier is retained to preserve exact build provenance.

Back up existing configuration, keys, and recordings before flashing. Use the
matching image, checksum, and provenance assets attached to this release;
the older rc.4 image does not contain the repairs below.

TeslaUSB Enhanced is an independent, unofficial project, not endorsed by or
affiliated with Tesla, Raspberry Pi, or the upstream TeslaUSB maintainers.

First-boot repairs

• The image build removes the standalone Raspberry Pi OS resize token while
  preserving the generated root=PARTUUID=... and unrelated boot options.
• The build and post-build verifier require exactly one rootwait and one
  modules-load token whose module list begins with dwc2,g_ether, while
  preserving deduplicated extra modules. Multiline or malformed boot command
  lines are rejected.
• Transaction recovery is installed only after TeslaUSB has created and
  mounted /mutable, avoiding the rc.4 first-setup ordering failure.
• Normal read-only boots no longer print harmless boot-log write errors, and a
  failed one-time repair hook is retained for retry.
• Read-write maintenance resolves the actual /boot or /boot/firmware mount
  behind /teslausb, verifies both remounts, and reports failure instead of
  silently leaving the boot filesystem read-only.
• Camera-only diagnostics no longer flag the optional media-drive web mount as
  missing when no Music, LightShow, or Boombox image exists.

Runtime and filesystem safety

• USB-export mount checks use compatible findmnt arguments and fail closed
  when mount state cannot be established.
• Filesystem checks run while the USB gadget is detached and the shared
  snapshot/gadget locks are held. Checks also reject mounted aliases of the
  same backing image.
• A dedicated filesystem helper verifies the result after any repair and
  manages bounded, temporary swap for memory-constrained devices. A failed
  live-image check prevents snapshot cleanup and USB export, rather than
  entering an automatic repair/restart loop. Ordinary lock contention remains
  retryable.
• Failed snapshot creation detaches its loop device and does not publish an
  incomplete snapshot in the recording index.
• Network-time verification handles the installed NTP tools' actual output,
  rejects stale samples, and verifies a fresh result after a clock correction.
  The dashboard distinguishes the last verified time from a continuously
  synchronized-clock claim.

SSH and advanced maintenance

• Fresh images keep the default login account locked. The setup wizard can
  include the user's SSH public key; private keys are not included in the
  configuration or release image.
• The Advanced maintenance panel reports SSH status, provides a copyable
  connection command, and offers bounded log downloads. It is not a web shell
  and does not execute arbitrary commands.
• The read-only health summary separates snapshot-storage space from the
  uninspected live camera filesystem. It reports the cleanup reserve,
  completed-snapshot metadata, retained cleanup evidence, clock status,
  system mount modes, and recovery-backup inventory when available.
• Recovery-backup allocation is explicitly not presented as reclaimable
  space: copy-on-write extents can be shared with other files.

Viewer responsiveness and usability

• The Viewer initially loads the newest available recording day. Older days
  are loaded on demand, and Refresh recordings is serialized with existing
  status and metadata requests.
• Recording-list scans are bounded and return meaningful errors. Browser
  timeouts, network failures, and cancelled requests are distinguished; a
  failed refresh retains the previous library and selection.
• Refresh and day changes briefly release the viewer's media downloads so
  six camera streams cannot occupy all browser connection slots needed by
  control requests. Returning to the same recording restores its camera
  positions, audio settings, playback rate, and playing/paused state.
• Leaving Viewer releases its video downloads for Tools, maintenance, and
  other tabs. Returning restores only the current selection, after any
  in-flight library request settles. Failed playback restoration is bounded
  and offers a retry. These browser-only pauses do not stop car recording.
• Freshness labels identify the library as completed snapshots, not a live
  view of the camera disk, and show the selected day's newest indexed camera
  timestamp without assuming its timezone.
• Touch playback controls remain visible. Small storage figures use MiB so
  the mutable/log partition's capacity is readable.

Read-only logging and image defaults

• Runtime logging uses bounded RAM storage, avoiding root-filesystem write
  failures and restoring read-only mounts cleanly after maintenance. Log
  persistence and retained evidence are reported without promising that RAM
  logs survive a reboot.
• Fresh-image configuration disables blanket passwordless sudo and
  cloud-init in favor of TeslaUSB's own setup flow. Existing installations
  are not blindly reconfigured by a source update.

Configuration and storage safety

• The offline wizard asks for the card's advertised decimal capacity and
  rejects a camera image above the conservative ceiling for that card.
• CAM_SIZE uses an explicit G suffix denoting GiB. Unitless values,
  unsupported units, undersized images, arithmetic overflow, and impossible
  allocations fail before setup.
• Wizard text is ASCII-safe so locally opened copies do not display corrupted
  punctuation when a browser or filesystem supplies the wrong encoding.

Encrypted recording boundary

• An empty TeslaCam/EncryptedClips placeholder no longer causes a false
  encrypted-recording warning.
• Any entry, hidden entry, directory, link, non-directory object, or unknown
  inspection state remains protected without reading encrypted clip contents.
• Unknown inspection results remove stale dashboard status so an old clear
  result cannot remain visible while automation is failing closed.

Image and hardware

• Built from 64-bit Raspberry Pi OS Lite (Debian Trixie) for arm64.
• Primary hardware target: Raspberry Pi Zero 2 W.
• A high-endurance microSD card of at least 64 GB is required; the wizard and
  README provide conservative CAM_SIZE ceilings for common card capacities.
• Connect the vehicle to the Zero 2 W's USB data/OTG port, not its
  power-only port.

Verification

Automated source validation covers the runtime, configuration, security,
maintenance APIs, and browser-helper regressions. The image passed offline
filesystem, boot-command-line, configuration, source-manifest,
credential-absence, and package checks. All four downloaded release assets
were independently checksum-checked, and the decompressed image matched its
recorded hash and privacy checks.

Selected fixes have been exercised on an existing Zero 2 W installation,
including reboot and Wi-Fi access, vehicle USB recognition, new Sentry
recordings and their appearance in completed snapshots, older-day playback,
viewer refresh/day changes, and a recording download.

TeslaUSB Enhanced v1.2.0-rc.4

TeslaUSB Enhanced v1.2.0-rc.4

Superseded — do not flash this image for a fresh setup. Use the newly
built rc.5 prerelease
and its matching checksum. The rc.4 assets are retained for provenance and
have not been replaced or relabeled. See the known first-boot issue below.

This is an unofficial prerelease of TeslaUSB Enhanced for the Raspberry Pi
Zero 2 W. It is intended for early testing before a stable image release. Back
up your existing TeslaUSB configuration and recordings before flashing it.

This candidate supersedes the unpublished v1.2.0-rc.3 draft. The rc.3 native
image build completed, but its post-build verifier stopped before compression,
upload, or publication. No rc.3 image assets were published. This candidate
corrects the verifier and release-control assumptions discovered by that live
build:

• The trusted checked-in image verifier runs with read-only root access so it
  can inspect root-only log, NetworkManager, and credential locations instead
  of silently missing protected paths.
• Generated package and metadata manifests are checked before their ownership
  is returned to the Actions runner account.
• Loop-device attach and detach commands use syntax supported by the hosted
  Ubuntu arm64 runner, while preserving strict canonical-image and
  /dev/loopN validation.
• Fresh Git tags are validated from GitHub's creation response and receive a
  bounded visibility interval before draft-release creation. Release creation
  is never blindly repeated.
• The current rpi-resize.service remains disabled and verified, preserving the
  unpartitioned card space TeslaUSB requires.
• The first-boot SSH marker is placed on the FAT boot partition at
  /boot/firmware/ssh; the obsolete root-filesystem marker is rejected.
• Trixie's rpi-swap and systemd-zram-generator packages are purged, and
  dpkg-db-backup.timer is disabled and verified.

Known issue discovered after publication

The published rc.4 image still contains the standalone Raspberry Pi OS
resize token in cmdline.txt. That early-boot trigger can expand the root
filesystem across the card even though rpi-resize.service is disabled,
leaving no free space for TeslaUSB's backing-file and mutable partitions. The
complete fix requires a newly built rc.5-or-newer image; the rc.4 image must not
be described as containing that repair.

Image and hardware

• Built from 64-bit Raspberry Pi OS Lite (Debian Trixie) for arm64.
• Target hardware: Raspberry Pi Zero 2 W.
• A 64 GB microSD card is the minimum. A high-endurance 128 GB card is
  recommended for higher recording capacity and write durability.
• Connect the vehicle to the Zero 2 W's USB data/OTG port, not its
  power-only port.
• Public release assets require no GitHub sign-in. If this historical release
  is hosted in a private mirror, an authorized account is required instead.

Flashing with Raspberry Pi Imager

1. Download
   teslausb-enhanced-v1.2.0-rc.4-pi-zero-2w-arm64-trixie.img.xz from this
   release.
2. Open Raspberry Pi Imager and choose Use custom.
3. Select the downloaded .img.xz file directly. Do not extract it first.
4. Select the microSD card and write the image.
5. If Raspberry Pi Imager offers to apply OS customization settings, decline
   them. TeslaUSB uses its own offline configuration workflow.

Configure before first boot

The image contains no Wi-Fi password, archive password, SSH key, API token, or
other user credential.

1. After flashing, reopen the card's boot partition.
2. Open teslausb_config_wizard.html locally in a modern browser.
3. Fill in the required settings and download the generated
   teslausb_setup.json.
4. Copy that file to the root of the boot partition with the exact filename
   teslausb_setup.json. Remove browser-added suffixes such as (1).
5. Safely eject the card before inserting it into the Pi.

Set WIFI_COUNTRY explicitly to the correct two-letter country code. The Pi
Zero 2 W needs a 2.4 GHz Wi-Fi network with Internet access during initial
setup. Use unique, strong credentials and review the wizard's recommended
values before saving the configuration.

Behavior and upgrade boundary

• Tesla recordings with EncryptedClips are detected and warned about only.
  Built-in automation does not decrypt, read, archive, play, move, or delete
  encrypted clip contents.
• Do not attempt an in-place upgrade from Bookworm or a 32-bit installation.
  Flash this Trixie arm64 image cleanly and restore settings through the JSON
  configuration.
• This prerelease includes guarded USB gadget repair, transactional application
  updates with rollback, strict declarative JSON configuration, archive
  reliability checks, and the offline configuration wizard.

Integrity and provenance

The release includes four image assets:

• the compressed .img.xz image;
• its .sha256 checksum file;
• image/build metadata JSON with exact TeslaUSB and pi-gen commits; and
• a complete installed-package manifest.

The automated release job verifies the partition table and filesystems,
arm64/Trixie identity, Pi Zero 2 W boot files, USB OTG configuration, locked
default account, clean machine identity, absent SSH host keys and random seed,
absent active setup credentials, embedded-source manifest, package inventory,
compression integrity, and uploaded asset digests before publication.

These checks are extensive but are not a substitute for physical hardware
testing. A complete first-boot, Wi-Fi, USB gadget, archive, and Tesla vehicle
test on a Raspberry Pi Zero 2 W is still pending for this prerelease.

The TeslaUSB and pi-gen source revisions are pinned and recorded, but the image
is not guaranteed to be bit-for-bit reproducible: Debian and Raspberry Pi
APT repositories can publish newer package builds over time. The included
package manifest and metadata record what was actually built.

License and names

This derivative is distributed under the included MIT license. It is an
independent, unofficial project and is not endorsed by or affiliated with
Tesla, Inc., Raspberry Pi Ltd., or the upstream TeslaUSB maintainers. Product
and project names belong to their respective owners.

TeslaUSB Enhanced v1.1.0

TeslaUSB Enhanced v1.1.0 is a quality-of-life and safety release for Raspberry Pi Zero 2 W, targeting 64-bit Raspberry Pi OS Lite based on Debian Trixie.

Highlights

• Manual USB gadget repair (14): adds an operator-initiated, two-confirmation dashboard action with shared locking, rate limiting, bounded helpers, backing-image preflight, and post-rebuild UDC/LUN verification. A failed verification leaves the gadget safely disconnected.
• Transactional application upgrades (15): stages checksum-verified, content-addressed /root/bin releases; activates them atomically; health-checks services; recovers interrupted/failed activation; reconciles stale managed links; and provides status, recovery, verification, and rollback commands.
• Strict declarative configuration (16): introduces teslausb_setup.json with native JSON types, a fixed allowlist, ownership/mode enforcement, no shell evaluation, duplicate/type/range checks, and a safe migration tool for deprecated legacy .conf files.
• EncryptedClips detection and warning only (17): reports encrypted recordings in the dashboard, archive log, and /api/v1/status. TeslaUSB does not request keys, decrypt clips, or open their contents, and built-in automation does not archive, play, move, or delete them.

EncryptedClips safety boundary

• Every built-in camera snapshot path, including Samba, uses one guarded lock across disconnect, live directory detection, unmount, and block-level copy.
• Camera snapshots and camera-clip archiving pause while EncryptedClips is detected; independent music sync continues.
• Protected or uninspectable legacy snapshots are retained during automatic cleanup.
• Literal paths and resolved aliases into EncryptedClips are excluded from archive manifests and the built-in viewer.
• Arbitrary trusted root hooks remain outside this built-in policy boundary.

Raspberry Pi Zero 2 W image recipe

• Targets arm64 Raspberry Pi OS Lite / Debian Trixie.
• Pins official pi-gen arm64 commit ca8aeed0ae300c2a89f55ce9617d5f96a27e99e5, current when this release was prepared.
• Embeds the exact committed TeslaUSB source with version, provenance, license, and SHA-256 manifests.
• Disables passwordless sudo and cloud-init and locks the known image password in the offline root filesystem before first boot.
• Pins tzupdate to 2d41763825fcfae3f2266bf1628ce245ab285f5a with SHA-256 7e6769fcf6c2a19a3492a9d62bd529714081132b12244796a4800269804857cb.

Validation

• GitHub Actions run #16 passed on the exact release head: ShellCheck, Python, JavaScript, C++/FUSE compilation, sudoers, nginx, real flock, root ownership, and the full shell/archive integration suite.
• Merged via PR #2 as commit dcb202fe2738a2cfc7517fbe711d95ff6b52079f.
• Based on upstream TeslaUSB main-dev commit fb4ed15b46dc41a2ec7c8a7a2fe0783ce1d2ffd9.

Compatibility and release boundary

• This is a source-only release; no prebuilt .img is attached.
• CI validates the code and reproducible source-staging path, but no complete pi-gen image build or physical Raspberry Pi Zero 2 W/Tesla hardware test is claimed.
• Do not perform an in-place Bookworm-to-Trixie or 32-bit-to-64-bit upgrade. Back up configuration and keys, flash a clean 64-bit Trixie image built from the included pinned recipe, then restore them.
• Transaction rollback covers managed application files only—not OS packages, firmware, partitions, configuration, credentials, archive data, or separately managed binaries.

TeslaUSB Enhanced v1.0.0

First stable release of the private TeslaUSB Enhanced distribution, based on upstream main-dev commit fb4ed15b46dc41a2ec7c8a7a2fe0783ce1d2ffd9.

Highlights

• Versioned local Web API, safer file operations, diagnostics, archive progress, bounded speed testing, and a responsive, accessible dashboard.
• SHA-256 archive manifests, source/destination verification, race-safe cleanup, bounded retries, and persistent transfer status.
• Fail-closed destructive-drive selection plus hardened SSH, Samba, Wi-Fi, host validation, nginx, CGI, and sudo boundaries.
• Web authentication enabled by default with generated root-only credentials when explicit credentials are not supplied.
• Pinned and checksum-verified optional Web UI and BLE artifacts, isolated Python dependencies, and bounded network operations.
• Local configuration generation, preflight checks, secret sanitization, expanded documentation, and substantially broader automated tests.

Validation

The exact release candidate passed GitHub Actions before merge, including ShellCheck and shell syntax, Python and JavaScript tests, FUSE compilation, nginx and sudoers validation, and setup/archive/runtime/security integration tests. Desktop and mobile dashboard smoke tests also passed.

Compatibility

This baseline release uses the Raspberry Pi OS Bookworm image line. Raspberry Pi OS Trixie and Raspberry Pi Zero 2 W-specific release safeguards are being delivered in the next separately tested release.

Known limitation

Tesla encrypted Dashcam clips are not decrypted, archived, or played. Standard unencrypted recordings remain supported.

See CHANGELOG.md for the complete release record.