lfg2025/archy
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases 44 Wiki Activity

[Bug] Install on 192.168.1.70: errors at DID-creation + password screens; FIPS slow to start #43

New Issue
Closed
opened 2026-06-17 08:16:34 +00:00 by lfg2025 · 1 comment
lfg2025 commented 2026-06-17 08:16:34 +00:00
Owner
Copy Link

During install on 192.168.1.70, errors appeared at the nostr/DID ID creation screen and the password-setting screen, though the install otherwise seemed to complete. FIPS did not start right away (eventually started, not too long — possibly acceptable).

Investigate: inspect install logs on .70; determine whether the DID/password screen errors are cosmetic (operation actually succeeded) or real; confirm the FIPS start delay isn't a race worth hardening.

During install on 192.168.1.70, errors appeared at the nostr/DID ID creation screen and the password-setting screen, though the install otherwise seemed to complete. FIPS did not start right away (eventually started, not too long — possibly acceptable). Investigate: inspect install logs on .70; determine whether the DID/password screen errors are cosmetic (operation actually succeeded) or real; confirm the FIPS start delay isn't a race worth hardening.
lfg2025 commented 2026-06-17 19:09:03 +00:00
Author
Owner
Copy Link

Implemented (code complete; live re-test on a fresh ISO node pending).

Root cause of the DID-creation/password errors: seed.generate was not idempotent. The web client aborts a slow request at 15s and retries internally (up to 3x), and the onboarding view also re-fired every 4s while the server was still booting — so on slow first-boot hardware each hit minted a new seed and overwrote the node keys mid-flight, leaving the words shown to the user out of sync with what seed.verify expected.

Changes:

  • seed_rpc.rs: handle_seed_generate now serializes under a lock and is idempotent — a fresh pending mnemonic is returned as-is instead of regenerating/overwriting keys. seed.verify no longer wipes the mnemonic on success (bounded by the 10-min TTL), so an internal retry can't trip "session expired".
  • OnboardingSeedGenerate.vue: distinguishes transient (server-starting → silent retry) from genuine failures (real message + manual "Try again"); generate timeout raised to 30s.
  • OnboardingSeedVerify.vue: server-starting hiccups now read as "still starting, tap Verify again" rather than a scary error.
  • OnboardingDone.vue: non-blocking "Securing your private connection…" status polling fips.status, so post-onboarding FIPS activation reads as in-progress rather than stuck.

Backend cargo check + frontend vue-tsc both pass. Full closure still wants a fresh install watched on a reachable node (.198 / scratch box), then a re-test on .70 once reachable.

**Implemented (code complete; live re-test on a fresh ISO node pending).** Root cause of the DID-creation/password errors: `seed.generate` was **not idempotent**. The web client aborts a slow request at 15s and retries internally (up to 3x), and the onboarding view *also* re-fired every 4s while the server was still booting — so on slow first-boot hardware each hit minted a **new** seed and **overwrote the node keys mid-flight**, leaving the words shown to the user out of sync with what `seed.verify` expected. Changes: - `seed_rpc.rs`: `handle_seed_generate` now serializes under a lock and is idempotent — a fresh pending mnemonic is returned as-is instead of regenerating/overwriting keys. `seed.verify` no longer wipes the mnemonic on success (bounded by the 10-min TTL), so an internal retry can't trip "session expired". - `OnboardingSeedGenerate.vue`: distinguishes transient (server-starting → silent retry) from genuine failures (real message + manual "Try again"); generate timeout raised to 30s. - `OnboardingSeedVerify.vue`: server-starting hiccups now read as "still starting, tap Verify again" rather than a scary error. - `OnboardingDone.vue`: non-blocking "Securing your private connection…" status polling `fips.status`, so post-onboarding FIPS activation reads as in-progress rather than stuck. Backend `cargo check` + frontend `vue-tsc` both pass. Full closure still wants a fresh install watched on a reachable node (.198 / scratch box), then a re-test on .70 once reachable.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lfg2025
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lfg2025/archy#43
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?