Moved the bolt→SQLite migration out of main and into an init step (startos/init/migrateSqlite.ts), driven by runUntilSuccess — pushed to next (7b79ea9).

What changed

• startos/init/migrateSqlite.ts (new): setupOnInit gated on needsSqliteMigration(); when a conversion is pending it builds a one-oneshot sdk.Daemons.of(effects).addOneshot('migrate-sqlite', …).runUntilSuccess(…). Wired into init/index.ts right after setupCerts (the conversion curls a temporary LND on 127.0.0.1, and setupCerts is what writes the tls.cert covering that SAN).
• main.ts: dropped the migrate-sqlite oneshot, the db-migration health check, and the needMigration gating. The lnd daemon no longer requires the migration. main is now migration-agnostic — by the time it runs, the node is already on SQLite.
• The verified conversion logic is unchanged (runSqliteMigration → schema-finalize run on bolt + lndinit migrate-db). Only where it runs moved. Removed sqliteMigrationComplete (it only fed the deleted health check), pruned the now-dead Database Migration i18n strings across all locales, and refreshed the README migration section (dropped the health-check row).

Verified: tsc --noEmit clean under SDK 2.0.3, ncc build clean, make x86 packs a valid s9pk. (The migration itself needs a real pre-0.21 bolt node to exercise end-to-end — not reproducible in the build sandbox.)

Two things worth a look:

1. Progress visibility. In main the conversion surfaced a Database Migration health check ("Migrating the database to SQLite… — do not interrupt"). As an init step it runs before the service starts, so the UI shows the generic initializing state instead — no "don't interrupt" message. The release notes already say the first start "may take a while," so I left them as-is, but if you want a user-facing cue during the conversion I can add a notification at migration start.
2. runUntilSuccess shape. I kept it as a single oneshot (the "Oneshots Only… like database migrations" pattern from the recipe), so the temporary LND is still spawned/killed inside finalizeBoltSchema. The more idiomatic alternative is to let runUntilSuccess manage LND as a real daemon in the chain (daemon = schema-finalize LND, dependent oneshot = unlock + wait, then a second chain for lndinit), which would delete the manual sub.spawn/child.kill. I went with the lower-risk single-oneshot since I can't run the real migration here to re-validate a rewrite — happy to switch to the daemon-managed shape if you'd prefer it.

One behavioral note on failure handling: runUntilSuccess only surfaces a failed oneshot via its timeout (it doesn't fail fast), so I set a generous 60-min backstop. On a genuine error the conversion throws early and, being resumable, retries on the next init.

Rewrote the migration to the idiomatic runUntilSuccess path — LND now runs as a managed daemon in the chain instead of the hand-rolled sub.spawn/child.kill. Force-pushed as one squashed commit (e89733c).

Design — two runUntilSuccess chains (it has to be two, because stage 2 needs LND stopped):

1. finalize-schema — a daemon (lnd-schema: LND on bolt+neutrino, --db.backend=bolt) whose ready check passes once the wallet unlocker is serving (LOCKED), plus a dependent oneshot that unlocks the wallet and waits for UNLOCKED. LND applies the channeldb schema migrations during unlock, so UNLOCKED is the guarantee they're done. runUntilSuccess then tears LND down.
2. lndinit-migrate — a oneshot running lndinit migrate-db, in a separate subcontainer, with LND fully stopped.

Why the design is shaped this way (from reading the SDK 2.0.3 source, since the old internals weren't trustworthy):

• Daemon.term() awaits the process exiting and then destroys the subcontainer. So chain 1 fully stops LND before chain 2's lndinit opens the db (no half-open-db race) — but a term'd subcontainer is one-way destroyed, so each chain gets its own (lnd-schema / lnd-lndinit).
• Daemons auto-restart on crash (backoff), and oneshots auto-retry on failure (only a successful exit breaks the loop). So a transient LND/unlock hiccup recovers inside the chain; the finalize oneshot is idempotent across retries (unlock tolerates "already unlocked", the wait is a poll). lndinit is idempotent too (tombstones, exits 0 on re-run).
• defaultTrigger polls every 1s while "starting", so the ready gate fires promptly — no custom trigger needed.
• restlisten is enforced to 0.0.0.0:8080, so the migration's 127.0.0.1:8080 REST calls are reachable.

Also dropped the per-call waitForState timeout — the runUntilSuccess timeout (30 min/stage, generous; resumable) is now the single bound.

Verified: tsc clean (SDK 2.0.3), ncc build clean, make x86 packs a valid s9pk.

Not verified end-to-end: exercising the actual conversion needs a real pre-0.21 bolt LND node with channel state, which I can't stand up in the build sandbox (old LND + wallet + mainnet channel.db). The mechanics follow the documented runUntilSuccess recipe and the SDK's teardown/retry semantics above, but if you want a live smoke test I'd need a bolt-format data set to point it at — let me know if you have one or want me to try building one on a VM.

Tested the upgrade end-to-end — it works. ✅

Installed the released 0.20.1-beta:13 (bolt) on a StartOS master VM, set backend=neutrino, initialized a wallet, and started it → bolt channel.db created (channeldb schema v33). Stopped it, then sideloaded this PR's build (0.21.1-beta:0, e89733c) as an upgrade. The migration ran during init exactly as designed:

Migrating 0.20.1-beta:13 -> 0.21.1-beta:0
Launching lnd-schema...                       # chain 1: LND-on-bolt daemon
CHDB: Checking for schema update: latest_version=35, db_version=35   # 33 -> 35 applied
Launching finalize-schema...                  # dependent oneshot
BTWL: The wallet has been unlocked without a time limit
Launching __RUN_UNTIL_SUCCESS...              # chain 1 sentinel -> LND torn down
Launching lndinit-migrate...                  # chain 2: LND stopped
MIGKV-channeldb: Migrating root bucket: open-chan-bucket   # ...all buckets...
LNDINIT !!!Migration of all mandatory db parts completed successfully!!!
LNDINIT Migrated DBs: [channeldb macaroondb decayedlogdb walletdb neutrinodb]
Initialization complete.

After the migration:

• data/graph/mainnet/ now has channel.sqlite (+ -shm/-wal) and lnd.sqlite; the old channel.db is tombstoned with a channel.db.migrated-to-sqlite-… marker.
• Started the service → LND 0.21.1-beta comes up on SQLite, wallet unlocks, lncli getinfo returns version: 0.21.1-beta and the node identity_pubkey (wallet intact).
• Restarted again → the migration did not re-run (needsSqliteMigration() short-circuits once channel.sqlite is present / dbMigrationComplete is set) — straight to the normal main chain.

So the two runUntilSuccess chains behave as intended on a real bolt→SQLite upgrade: schema-finalize daemon → teardown → lndinit on the closed db → node up on SQLite. (Tested on neutrino to avoid needing a synced bitcoind; the conversion path is backend-agnostic.)

Added init-progress reporting for the migration (f6b8d61).

The init framework hands each setupOnInit handler a FullProgressTracker as its 3rd arg (auto-syncs to setInitProgress in the background). The migration now reports two named phases so the StartOS update UI shows what's happening instead of a bare "initializing":

progress.addPhase('Finalizing database schema')  // chain 1
progress.addPhase('Copying database to SQLite')   // chain 2

Each is start()ed when its stage begins and complete()d when done (the schema phase completes even on a resumed run). Phase names are localized across all locales. runSqliteMigration's param is typed against a minimal structural view of the tracker so it doesn't reach into the SDK's non-exported class.

Verified on the same real upgrade path: during the conversion the package sits in updating and both phases show up in its progress state —

state=updating  phases_seen=['Finalizing database schema', 'Copying database to SQLite']

— then it flips to installed and the node comes up on SQLite (channel.sqlite/lnd.sqlite present, old bolt DBs tombstoned, lncli getinfo → 0.21.1-beta). So the migration still works end-to-end, now with visible progress.

wtclient.db version-0 migration blocker

Added handling for a bolt→SQLite conversion failure @DRBoneZ hit on upgrade:

LNDINIT Runtime error: refusing to migrate source database with version 0 while
latest known DB version is 8; please upgrade the DB before using the data
migration tool or delete the wtclient.db manually ...

Cause. lndinit migrate-db version-checks exactly two DBs before copying — channel.db and wtclient.db — and hard-aborts the whole run if either isn't at its latest schema (cmd_migrate_db.go → checkWTClientDBMigrationsApplied). LND < v0.14.0-beta (commit 75531455daf0, Dec 2021) created wtclient.db unconditionally, but only wrote its schema version when the client was actually run — so any node whose data dir predates that (or briefly toggled the watchtower client on then off) carries an empty, version-0 wtclient.db. Current LND gates both on wtclient.active, so it can't produce this state; it's purely a legacy-data artifact. That's a large share of long-lived nodes, not an edge case.

Fix. In finalizeBoltSchema, when a wtclient.db is present, add --wtclient.active to the schema-finalize LND run. LND then applies the pending wtclient migrations during BuildDatabase (which completes before the wallet reaches UNLOCKED, so the existing gate already covers it), bringing the db to version 8 before lndinit runs.

Why activate-and-migrate rather than delete (the error's other suggestion): it's lossless in every case. An empty (v0) db is simply initialized to v8; a db from prior watchtower use (versions 1–7 are real, data-bearing schemas) keeps its session data. A blind rm would be safe only for the v0 case. An absent wtclient.db is left untouched — lndinit cleanly skips a missing optional db.

Verified against lndinit v0.1.36-beta and lnd v0.21.1-beta source (with an adversarial re-audit of the losslessness invariant and the db-discovery/skip logic).

Build: tsc --noEmit and the ncc bundle pass. Could not run the full s9pk pack locally (the shared buildx builder has a broken DNS resolver in this environment — unrelated to this diff, which touches no Dockerfile/manifest); CI runs the full pack.

Side note (out of scope, possible follow-up): the neutrino-based finalize run creates a fresh neutrino.db on bitcoind nodes that lndinit then copies to an inert neutrino.sqlite — harmless, but wastes some space and raises lndinit's peak free-space requirement. Worth a look separately.