Repository navigation
Browser on the Jetson: per-launch overlay instead of a disk copy (#90) - #531
Merged
Merged
Conversation
…wser Brings the reviewed Jetson Browser candidate 2ec039f (#90) onto develop. Conflicts: release-upstream-recipes.json keeps develop's Node 24.22.1 pins and the candidate's crosvm lifecycle and vhost-device-vsock rows, with the browser-upstream-build.py checksum recomputed for the merged script; the Linux network helper and its test are the candidate's reviewed bytes (installed on the Jetson, SHA-256 235a0fec...), which supersede the 12 Oct qualification commits; the catalog read model keeps develop's capsule_is_offered filter and uses the candidate's Home-level Browser availability; the TURN readiness fixture combines develop's event/arch/tool mocks with the candidate's native capability contract. The home summary test follows the same Home-level availability.
This reverts commit dfd6132 on the Jetson Browser integration branch (#90). It is the only guest-input change in the merged candidate; without it the guest inputs equal the signed 2.0.0 Browser image (bb8a247c...), so that image is reused byte-exact. Close keeps the shipped writer grace wait. The guest change waits for the next image batch.
…e develop merge develop moved the control config into vmControlServiceConfig and dropped the local launcher variable from ensureVmControlAvailable; the merged #90 check still read it, so prewarm on an unsupported host threw ReferenceError "launcher is not defined" instead of host_unsupported. Resolve the launcher where it is needed. Regression: browser-vm-engine-supervisor.test.mjs "the actual prewarm command explains an unsupported local host" failed before (stderr not JSON) and passes after.
components.json had a browser-vm-image row only for darwin-arm64, so setup on
a Jetson always refused the image ("Browser image release package is
unavailable for linux-arm64") and no linux-arm64 Home could open Browser.
Add a linux-arm64 row for the same ARM64 guest bytes under its own
release_path, browser-vm-image-linux-arm64.tar.gz, because a capsule record
names one platform (check-product-data refuses a shared release_path).
release-package.yml: the aarch64-linux N build passes the same workflow image
inputs as the Mac (--browser-vm-image-cid/-sha256/-size from
inputs.browser_image_*); x86-64 Linux still takes none. Publication already
treats identical same-named artifacts as one universal asset; both rows carry
the same CID, so the seed stores the bytes once.
Tests: ci-release-policy-test hermetic build covers mac, aarch64-linux and
x86_64-linux image arguments; release-platform-input-test stages the checkout
rows for both ARM64 hosts and refuses Linux ARM64 fresh support without the
image (red on the old template); the Rust manifest test asserts both rows.
a9f25bd's manifest test called unwrap_err on Result<&PlatformInfo, _>, which does not compile (PlatformInfo has no Debug). Use err().expect().
#90) Runtime setup admits only prepared Browser host rows (browser_config::host_rows refuses strategy source-build). setup-source-home stamped the installed helper bytes' checksum and size but kept source-build, so on the Jetson `elastos setup` reported "Browser host component 'browser-vm-engine-supervisor' requires a prepared release artifact" and never wrote the Browser Engine config. Mark them prebuilt, as the retained Browser packages already are. Regression: setup-source-home-native-browser-test full setup now asserts every stamped browser-host row is prebuilt (red before, green after).
…a dir (#90) Runtime probes --host-capabilities with a cleared environment and only ELASTOS_BROWSER_VM_DATA_DIR. The Linux owner resolved bin/vhost-device-vsock (and crosvm) from HOME/XDG instead, found nothing, and answered available=false (preparation_required), so on the Jetson setup always said "Browser requires its admitted native Engine and access to the selected KVM transport" though KVM, bwrap and the host network setup were ready (the same probe with HOME set answers available=true). Resolve the data dir once, from ELASTOS_BROWSER_VM_DATA_DIR first, for the launch paths, the userspace vsock backend and the crosvm provider. Test: runtime_selected_data_dir_wins_over_home_resolution.
On the Jetson the per-launch copy of the 4 GiB seed (cp --reflink=auto on ext4, SD card) ran >= 346 s, past the 300 s adapter cap, so Browser never opened. The native owner now renames one prepared copy of the admitted image from ELASTOS_BROWSER_VM_ROOTFS_POOL_DIR into the launch, copies the seed only when none is ready, and starts a background refill (the owner binary re-entered with --refill-rootfs-pool) that stops with the control service. A copy is used only when its name carries the manifest's rootfs hash and it is a private regular file of the seed's size owned by this user. Linux config passes the pool dir and a target of one copy.
… open (#90) On the Jetson's SD card a copy of the 4 GiB Browser image takes about six minutes, longer than a launch may run. The first copy is now made off the launch path: - The Browser control service starts one pool refill (the native owner re-entered with --refill-rootfs-pool) once the native Engine is ready at Home start; the refill stops when the service stops. - elastos setup makes the first copy after it installs the Browser image on Linux ARM and reports the time, or why it could not. - A launch that finds no ready copy while a refill is copying one waits for it when the copier's progress says it finishes within the launch limit (less a boot reserve); otherwise it fails at once with browser_getting_ready, "Browser is still getting ready on this computer. Open it again in about N minutes.", which Runtime and the Browser window pass through instead of a generic start failure. The refill takes its pool from the environment (only the pool inputs are passed) and prints a JSON summary: ready, busy, low_space, off or failed.
…ce log schema (#90) Seen on the Jetson: the refill summary's schema replaced the event schema in browser-vm-control-service.log.
… crosvm exit ends the launch and keeps its log (#90) crosvm's vhost-user frontend offers a 32768-entry vsock ring when max-queue-size is unset; vhost-device-vsock accepts at most its --queue-size (1024), drops the device, and crosvm stops the guest about 6 s after start (seen on the Orin). One constant now sets both sides. When crosvm or its backend exits on its own, the owner keeps the last 64 KiB of crosvm.log (serial console included) and 16 KiB of the backend log in <state>/last-vm-exit.log, and the vsock wait ends at once with that detail instead of at the startup observation budget.
… Linux hosts (#90) ELASTOS_BROWSER_VM_TEST_STARTUP_STEP_BUDGET_MS replaces the owner's 30 s per-step startup budget, ELASTOS_BROWSER_VM_TEST_NO_LAUNCH_REFILL keeps the launch from starting the rootfs refill, ELASTOS_BROWSER_VM_TEST_TRACE_FILE appends each owner startup stage with its wall-clock time, and ELASTOS_BROWSER_VM_TEST_HOST_READINESS_TIMEOUT_MS replaces the control service's 30 s host readiness probe limit. No Home config sets them; they exist only to measure the Jetson's real startup stages.
…er the launch (#90) On the Jetson's SD card the guest page open takes 32-33 s, and the owner cut every startup step at a fixed 30 s. The transport bootstrap and the page open are now observed for their own configured limits (ELASTOS_BROWSER_VM_TRANSPORT_BOOTSTRAP_TIMEOUT_MS, ELASTOS_BROWSER_VM_CONTROL_READY_TIMEOUT_MS) plus 5 s, read once before any effect; host-side steps keep 30 s. A Mac open that succeeds is unchanged. The launch no longer starts the rootfs pool refill when it takes its copy: a 4 GiB copy kept the SD card 98 % busy for 4 minutes while the page open read 690 MB. The owner starts it once the launch is ready, or once a failed launch's cleanup has ended. The owner keeps its startup stage times with the wall clock in <state>/last-launch-trace.log (0600, replaced by each launch; stage names only, no profile or boot arguments). The test-only overrides of 229ad75 (step budget, refill hold, trace file) are removed.
) A first launch that failed before the guest mounted its profile disk left the disk with only its creation marker, and every later open refused with "profile setup was interrupted" until Reset. The guest erases the marker and syncs before its only format attempt, so a disk whose header is still this profile's marker and that has no more than 1 MiB allocated was never written: the owner boots it as new again. A marker beside written data still requires recovery, bytes kept.
5 tasks
Contributor
Author
|
Source review found a blocking image-integrity issue. The Runtime verifier and host readiness accept a digest from the writable image identity record. A tiny fixture using the exact host-readiness helper returned the original expected digest after the image bytes changed and the record was rewritten with the current file identity. The expected digest stayed fixed. |
Remove writable verified-identity records from Runtime and shell preflight. Cache only digests hashed by this Runtime process and share startup verification with Browser opens. Use idle I/O and nice priority on the dedicated Linux startup thread. Cover forged records, identity changes, concurrent opens, startup warming and shutdown on Linux and Mac VZ.
This was referenced Nov 5, 2026
Open
Keep host readiness structural and limit its probe to ten seconds. Preserve the Runtime wait for startup verification outside the readiness budget. Carry the process-admitted seed identity in the launch request and check link and target metadata before the Mac copy or Linux overlay. Verification: 500 local Rust tests pass; Clippy passes for server and VZ across all targets; source gate passes. Regression baselines reject the old host hashing and probe limit, and expose the unchecked changed seed. Publisher digest authority remains tracked separately in #534.
…quests (#90) Send verified_rootfs only for a Runtime-admitted seed. Publish terminal failure and wake preparation and launch waiters when a worker is cancelled or panics, including before its first poll. Verification: named remote-engine replay and signed-approval regressions pass in the 40-test Mac focused run (4.73s); server and VZ Clippy pass across all targets. Full server and Linux checks follow on the combined candidate.
Start warmup only for a configured local Engine with installed image bytes. Share each image hash through its own completion state, keep filesystem work outside the cache lock, and release cancelled or failed waiters with an explicit error. Verification: startup and independent-Home regressions fail before the fix and pass in the 40-test Mac focused run (4.73s). Cancellation, panic, identity and cache-bound checks pass; all-target server and VZ Clippy pass. The added foreground/background cancellation check and full suites run on the combined candidate.
Contributor
Author
|
Bounded SOURCE PASS for the frozen correction: the writable digest-record finding is resolved. Runtime owns hashing and process-memory reuse; host readiness reports structure/capability, and the supervisor rechecks the admitted rootfs identity before copy/overlay. The wait/cancellation, panic-result publication and cache bounds have focused source regressions. |
This was referenced Nov 5, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deepen notes
scripts/browser-upstream-build.py); seccomp killed qcow reads (no pread64 in the aarch64 block policy).Problem
#90: ElastOS Browser on the Jetson (Linux ARM64). The first approach copied the 4 GiB system image for each launch; on an SD card that saturated the disk, slowed the whole host and made reopen and Close fail.
Change
net,qcow;pread64added to crosvm's aarch64 block seccomp policy by the recipe build). The overlay is deleted at launch end; a crashed launch's overlay is removed by the next launch; a launch refuses unless free space covers the seed plus 4 GiB. The shared writable seed setting is Mac-only. The copy pool, refill and prefill are removed, and setup removes an old pool folder.Jetson run on this exact head (1405adf, running binaries' sha256 checked)
Security repair after Codex Root's HOLD (5 Nov), timing on 53f417d (built from 53f417d)
The persistent verified-identity record is removed: only the Runtime verifies the image, from bytes it hashed itself, in memory, bound to file identity; host readiness checks shape only; the seed's identity is re-checked right before the overlay or Mac copy is created. A low-priority verification starts at Home start and a Browser open waits for it. The deeper pre-existing gap (expected digests in the user-writable image directory) is #534, a separate repair (Root agreed).
Not proven
An installed Home through a signed release (next: a 2.1.0 test release installed on the Jetson by update). The ops scripts' release prechecks (alpha-lib.sh musl_check, musl-precheck.sh) still need the linux-arm64 image inputs. Not run with the new root-owned network helper setup (the test Home used the helper already installed).