LND starting indefinitely on 0.4.0

stellarstoic · July 25, 2026, 4:07pm

I migrated to 0.4.0 and the LND is starting indefinitely. the logs are stuck on this wanting to unlock the wallet???

i think I lost the channels also because I tried to fix the issue with uninstalling the LND service. I only have the aezeed 24seed phrase yikes!

Two things that needed to migrate smoothly are Bitcoin core and LND and one of them filed badly.

StuPleb · July 25, 2026, 4:37pm

No, you actively uninstalling LND on your own initiative is not LND migration failing.

What are you trying to do now? You’re reporting an error after nuking your wallet. Have you created a new LND? Where and with what do you need help?

stellarstoic · July 25, 2026, 4:45pm

the issue I have is it’s stuck in this

2026-07-25T18:42:43+02:00 daemon sync-progress waiting on unlock-wallet
2026-07-25T18:42:43+02:00 daemon sync-progress waiting on unlock-wallet
2026-07-25T18:42:43+02:00 Launching unlock-wallet…

that’s all I see.

StuPleb · July 25, 2026, 4:49pm

OK, so I can determine you’re on v040 and you didn’t go back to v0351 to rescue your funds from backup.

I can guess that maybe you installed LND from scratch. Maybe? It should be creating a new wallet and not be in this state.

So I’m not sure, it seems I don’t have the whole story and the missing context.

stellarstoic · July 25, 2026, 4:59pm

I migrated to 0.4.0 normally, then I started launching services. Bitcoin Core was fine and Electrum worked, but when I tried to start LND, it didn’t start. Before I even check the logs, I reinstalled it. The installation succeeds every time, but I still can’t start the LND service.

Is there a way to roll back to the previous version? Since we all created a backup on v0.3.5.1—which isn’t compatible with v0.4.0—there should at least be a downgrade option.

StuPleb · July 25, 2026, 5:07pm

This would be incorrect. You’re expected to upgrade each service first. I’m not sure of the behavior of each service if you don’t.

To reflash StartOS v0351 and restore from backups, you’d follow the guides here:

Step 1 - Start9 | Flashing Guides
Step 2 - Start9 | Backup Restore

stellarstoic · July 25, 2026, 6:40pm

I tried to downgrade to 0.3.5.1 and followed the tutorials and after selecting… Recover > Use existing Drive > Selecting drive > I set a password > loader starts > after a minute In initializing mode I always get.

Error

RPC ERROR: Deserialization Error Deserialization Error: invalid type: null, expected struct ServerInfo.

Tried 3 times. always stuck on infinite Initializing StartOS loader

StuPleb · July 25, 2026, 11:23pm

You can’t use existing drive and preserve data. You have to factory reset your service, wipe it, and the restore your old backups

Bruce · July 31, 2026, 2:04pm

Good morning. I’m in the exact same state. However, I had problems with the upgrade process on my Server Pure. I had backups from 0.3.5.1 and restored them after reverting back to 0.3.5.1. No, I never re-ran LND or CLN after restoring the backup on 0.3.5.1—my next step was to upgrade to 0.4.0 via USB before running them.

Since I no longer see any passwords stored in 0.4.0, I suspect this has changed from 0.3.5.1. Previously, CLN passwords were stored and available to copy and paste. That appears to have been removed, forcing the operator to store these passwords elsewhere. My CLN is running, but my password from 0.3.5.1 is gone under 0.4.0.

Edit:
CLN node is back running. No closwd channels after resetting the UI password.
Now I just have this issue with LND.

StuPleb · July 31, 2026, 3:58pm

It’s definitely not a tested path to restore services (especially lightning, which behave uniquely) in 0351, not run them and then upgrade. It seems that combination of events caused CLN to skip force closing the channels. Hopefully nothing stuck that might cause problems later.

LND seems to have not been so lucky, but I can’t really begin to guess at the problem without seeing what the error is.

Bruce · July 31, 2026, 5:33pm

LND after attempting to restore the migrated 0.4.0 backup on both my start9 machines produces the same issue: Waiting for Start service to feed it the password to decrypt and unlock it.
Stuck right here:
2026-07-31T12:14:21-05:00 Started container-runtime.service - StartOS Container Runtime.
2026-07-31T12:14:24-05:00 Listening on /media/startos/rpc/service.sock
2026-07-31T12:14:30-05:00 Initializing…
2026-07-31T12:20:44-05:00 adding callback 1
2026-07-31T12:20:44-05:00 adding callback 2
2026-07-31T12:20:44-05:00 adding callback 3
2026-07-31T12:20:44-05:00 adding callback 4
2026-07-31T12:20:44-05:00 Initialization complete.
2026-07-31T12:22:49-05:00 Starting LND!
2026-07-31T12:22:49-05:00 adding callback 5
2026-07-31T12:22:49-05:00 adding callback 6
2026-07-31T12:22:49-05:00 adding callback 7
2026-07-31T12:22:49-05:00 .const() triggered
2026-07-31T12:22:49-05:00 Restarting service…
2026-07-31T12:22:49-05:00 daemon unlock-wallet waiting on lnd
2026-07-31T12:22:49-05:00 daemon sync-progress waiting on lnd,unlock-wallet
2026-07-31T12:22:49-05:00 daemon restore waiting on lnd,unlock-wallet
2026-07-31T12:22:49-05:00 daemon reachability waiting on lnd
2026-07-31T12:22:49-05:00 Launching lnd…
2026-07-31T12:22:49-05:00 daemon unlock-wallet waiting on lnd
2026-07-31T12:22:49-05:00 daemon sync-progress waiting on lnd,unlock-wallet
2026-07-31T12:22:49-05:00 daemon synced-true waiting on sync-progress
2026-07-31T12:22:49-05:00 daemon restore waiting on lnd,unlock-wallet
2026-07-31T12:22:49-05:00 daemon clear-restore-flag waiting on restore
2026-07-31T12:22:49-05:00 daemon reachability waiting on lnd
2026-07-31T12:22:51-05:00 2026-07-31 17:22:51.851 [INF] LTND: Version Info rev=2b8788 version=0.21.1-beta commit=v0.21.1-beta debuglevel=production logging=info
2026-07-31T12:22:51-05:00 2026-07-31 17:22:51.852 [INF] LTND: Network Info rev=2b8788 active_chain=Bitcoin network=mainnet
2026-07-31T12:22:51-05:00 2026-07-31 17:22:51.862 [INF] RPCS: RPC server listening on 0.0.0.0:10009
2026-07-31T12:22:51-05:00 2026-07-31 17:22:51.977 [INF] RPCS: gRPC proxy started at 0.0.0.0:8080
2026-07-31T12:22:51-05:00 2026-07-31 17:22:51.996 [INF] LTND: Opening the main database, this might take a few minutes…
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.759 [WRN] LTND: Found existing bbolt database file in /root/.lnd/data/chain/bitcoin/mainnet/wallet.db while using database type sqlite. Existing data will NOT be migrated to sqlite automatically!
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.759 [INF] LTND: Creating local graph and channel state DB instances
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.888 [INF] CHDB: Checking for schema update: latest_version=35, db_version=35
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.888 [INF] CHDB: Applying 2 optional migrations
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.888 [INF] CHDB: Checking for optional update: name=prune_revocation_log
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.888 [INF] CHDB: Checking for optional update: name=gc_decayed_log
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.888 [INF] CHDB: Performing database optional migration: gc_decayed_log
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.888 [INF] CHDB: Migrating decayed log…
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.888 [INF] CHDB: Decayed log migrated successfully
2026-07-31T12:22:54-05:00 2026-07-31 17:22:54.948 [INF] CHDB: Successfully applied optional migration: gc_decayed_log
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.037 [INF] SQLD: No database version found, using schema version -1 (dirty=false) as base version
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.037 [INF] SQLD: Migrating SQL schema to version 1
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.037 [INF] SQLD: Applying migrations from version=0
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.219 [INF] SQLD: 1/u invoices (181.717464ms)
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.273 [INF] SQLD: Migrating SQL schema to version 2
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.273 [INF] SQLD: Applying migrations from version=1
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.442 [INF] SQLD: 2/u amp_invoices (166.903781ms)
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.488 [INF] SQLD: Migrating SQL schema to version 3
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.489 [INF] SQLD: Applying migrations from version=2
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.642 [INF] SQLD: 3/u invoice_events (152.586284ms)
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.693 [INF] SQLD: Migrating SQL schema to version 4
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.693 [INF] SQLD: Applying migrations from version=3
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.805 [INF] SQLD: 4/u invoice_expiry_fix (111.659196ms)
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.854 [INF] SQLD: Migrating SQL schema to version 5
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.855 [INF] SQLD: Applying migrations from version=4
2026-07-31T12:22:55-05:00 2026-07-31 17:22:55.960 [INF] SQLD: 5/u migration_tracker (104.745855ms)
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.012 [INF] SQLD: Migrating SQL schema to version 6
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.012 [INF] SQLD: Applying migrations from version=5
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.155 [INF] SQLD: 6/u invoice_migration (143.219263ms)
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.208 [INF] SQLD: Migrating SQL schema to version 6
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.208 [INF] SQLD: Applying migrations from version=6
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.209 [INF] SQLD: Applying custom migration ‘kv_invoice_migration’ (version 7) to schema version 6
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.209 [INF] INVC: Starting migration of invoices from KV to SQL
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.209 [INF] INVC: All invoices migrated. Total: 0
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.210 [INF] INVC: Migration of 0 invoices from KV to SQL completed
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.269 [INF] SQLD: Migration ‘kv_invoice_migration’ (version 7) applied
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.317 [INF] SQLD: Migrating SQL schema to version 7
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.318 [INF] SQLD: Applying migrations from version=6
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.484 [INF] SQLD: 7/u invoice_add_settled_index (165.47728ms)
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.542 [INF] SQLD: Migrating SQL schema to version 8
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.542 [INF] SQLD: Applying migrations from version=7
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.740 [INF] SQLD: 8/u graph (197.325073ms)
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.796 [INF] SQLD: Migrating SQL schema to version 8
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.796 [INF] SQLD: Applying migrations from version=8
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.797 [INF] SQLD: Applying custom migration ‘kv_graph_migration’ (version 10) to schema version 8
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.797 [INF] SQLD: Migration ‘kv_graph_migration’ (version 10) applied
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.853 [INF] SQLD: Migrating SQL schema to version 9
2026-07-31T12:22:56-05:00 2026-07-31 17:22:56.853 [INF] SQLD: Applying migrations from version=8
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.031 [INF] SQLD: 9/u graph_v2 (177.219788ms)
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.090 [INF] SQLD: Migrating SQL schema to version 10
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.090 [INF] SQLD: Applying migrations from version=9
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.243 [INF] SQLD: 10/u payments (152.667486ms)
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.293 [INF] SQLD: Migrating SQL schema to version 11
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.293 [INF] SQLD: Applying migrations from version=10
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.439 [INF] SQLD: 11/u payment_duplicates (145.973559ms)
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.494 [INF] SQLD: Migrating SQL schema to version 11
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.494 [INF] SQLD: Applying migrations from version=11
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.494 [INF] SQLD: Applying custom migration ‘kv_payments_migration’ (version 14) to schema version 11
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.494 [INF] PYDB: Starting payment migration from KV to SQL…
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.495 [INF] PYDB: No payments bucket found - database is empty
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.495 [INF] PYDB: Found ~0 index entries to migrate (includes duplicates)
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.495 [INF] PYDB: No payments bucket found - database is empty
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.495 [INF] PYDB: No payments migrated - database is empty
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.495 [INF] SQLD: Migration ‘kv_payments_migration’ (version 14) applied
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.531 [INF] SQLD: Migrating SQL schema to version 12
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.531 [INF] SQLD: Applying migrations from version=11
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.685 [INF] SQLD: 12/u drop_redundant_invoice_indexes (153.80599ms)
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.735 [INF] SQLD: Migrating SQL schema to version 13
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.738 [INF] SQLD: Applying migrations from version=12
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.904 [INF] SQLD: 13/u payments_index_improvements (166.025203ms)
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.960 [INF] SQLD: Migrating SQL schema to version 14
2026-07-31T12:22:57-05:00 2026-07-31 17:22:57.961 [INF] SQLD: Applying migrations from version=13
2026-07-31T12:22:58-05:00 2026-07-31 17:22:58.131 [INF] SQLD: 14/u payments_no_fail_reason_index (170.046474ms)
2026-07-31T12:22:58-05:00 2026-07-31 17:22:58.191 [INF] SQLD: Migrating SQL schema to version 15
2026-07-31T12:22:58-05:00 2026-07-31 17:22:58.192 [INF] SQLD: Applying migrations from version=14
2026-07-31T12:22:58-05:00 2026-07-31 17:22:58.343 [INF] SQLD: 15/u chain_params (151.036502ms)
2026-07-31T12:22:58-05:00 2026-07-31 17:22:58.549 [INF] LTND: Database(s) now open (time_to_open=6.552643453s)!
2026-07-31T12:22:58-05:00 2026-07-31 17:22:58.549 [INF] LTND: We’re not running within systemd or the service type is not ‘notify’
2026-07-31T12:22:58-05:00 2026-07-31 17:22:58.549 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2026-07-31T12:22:59-05:00 daemon sync-progress waiting on unlock-wallet
2026-07-31T12:22:59-05:00 daemon restore waiting on unlock-wallet
2026-07-31T12:22:59-05:00 daemon sync-progress waiting on unlock-wallet
2026-07-31T12:22:59-05:00 daemon restore waiting on unlock-wallet
2026-07-31T12:22:59-05:00 Launching unlock-wallet…
2026-07-31T12:22:59-05:00 Launching reachability…

Bruce · August 1, 2026, 12:15am

@StuPleb Should I attempt to rebuild LND to see if this will get the wallet unlock issue resolved?

Edit:

Rebuilding the service did not solve the the unlock-wallet issue.

Is there a path here to fix why StartOS is not sending LND the required pasword?

Notice in the logs there are no LND issues at all. Looks to be a StartOS issue.

Summary of Steps & Expectations:

Flashed 0.3.5.1 - Factory Reset after OTA failure
Restored all services. Never ran them. Just restored them.
Flashed 0.4.0 - migration happened.
Ran CLN and LND, expecting them both to close out the channels. Expecting all necessary information like wallet-unlock is restored from backup.
CLN did not close the channels. In fact it is running fine. Sats are flowing in from mining pool.
LND however, reports no issues in log, waiting on Wallet unlock.., Its as if something was not restored/migrated correctly from my end. I was expecting it to run and close the channels.

No instructions provided that stated services needed to be ran on the version it was restored from first to have LND close out all the channels. I expected it still needed to run wallet unlock even for this.

Bruce · August 2, 2026, 12:22am

@StuPleb Last question for you and your team on my issue:

Does the 0.3.5.1-to-0.4.0 service migration preserve both LND’s walletPassword and its restored-node state in the format expected by the 0.4.0 unlock-wallet helper?

StuPleb · August 6, 2026, 8:54am

Short version: your wallet database is in the old bolt format, and the LND that ships on 0.4.0 only reads sqlite. The one-time automatic conversion that should have handled that didn’t run.

LND 0.21 (on 0.4.0) moved off the legacy bolt database to SQLite. Nodes coming from 0.3.5.x are on bolt, so the package runs a one-time conversion the first time LND starts after the update.

That conversion decides whether it’s needed by checking for channel.db, LND’s channel/graph database. That’s a fine signal for an upgrade, but it fails on a restore, because two things are both true:

channel.db is deliberately excluded from backups becasue restoring stale channel state is dangerous, and
LND only creates channel.db itself, on first startup.

You restored on 0.3.5.1 and went straight to 0.4.0 without starting LND. So there was no channel.db for the check to find, the conversion concluded there was nothing to convert, and LND 0.21 started on the SQLite backend, found no wallet there, and settled in to wait for a wallet that — from where it’s standing — doesn’t exist.

Your log catches it in the act, just before the stall:

Found existing bbolt database file in /root/.lnd/data/chain/bitcoin/mainnet/wallet.db while using database type sqlite. Existing data will NOT be migrated to sqlite automatically!

And right after, the SQL migrations run against a brand-new empty database — No database version found, All invoices migrated. Total: 0, No payments bucket found - database is empty. That is LND opening a fresh, empty SQLite wallet alongside your real one.

Does the 0.3.5.1-to-0.4.0 service migration preserve both LND’s walletPassword and its restored-node state?

Yes and no.

walletPassword – yes. It was carried across correctly. The unlock helper isn’t failing to send it; it never reaches the point of sending it, because it waits for LND to report a locked wallet and LND is reporting no wallet. That’s also why you saw no error — it’s waiting quietly rather than failing.
Restored-node state – no. The marker that tells LND to run the channel-backup restore is only set by a restore performed on 0.4.0. Yours happened on 0.3.5.1, and nothing carries it forward. Your channel.backup file is intact on disk, but the restore won’t run on its own — it’ll need to be triggered as a second step once the wallet is readable.

Had LND been started once on 0.3.5.1 it would have created channel.db, the conversion would have triggered, and your wallet would have converted with it — but you had no way to know that, and it isn’t documented and 99% of people should not be doing this.

Your on-chain keys are still in that bolt wallet.db, and your channel.backup is intact. The data is sitting there unread, not lost.

I’m going to see if I can fix it. The conversion needs to trigger on a restored wallet, not only on the presence of channel.db.