Raspiblitz: Stuck at Lightning Filtering Blockchain

[raumi75]

After rebooting, my Raspi is stuck this status for over one day.

~
Lightning Filtering Blockchain
Progress: ?/562483
Please wait - this can take some long time.
Its OK to close terminal and ssh back in later.
~

The bitcoin daemon works fine, but my lnd log looks like this:

~
2019-02-10 19:12:51.835 [INF] LTND: Version: 0.5.1-beta commit=, build=production, logging=default
2019-02-10 19:12:51.835 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-02-10 19:12:51.837 [INF] LTND: Shutdown complete
2019-02-10 19:13:52.311 [INF] LTND: Version: 0.5.1-beta commit=, build=production, logging=default
2019-02-10 19:13:52.311 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-02-10 19:14:52.776 [INF] LTND: Version: 0.5.1-beta commit=, build=production, logging=default
2019-02-10 19:14:52.776 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-02-10 19:14:52.778 [INF] LTND: Shutdown complete
~

[ln3r]

I had the same issue initially when updating to v0.99 - try CONTROL + C and then ./10setupBlitz.sh

[raumi75]

Thank you, @ln3r, I did this and got:

~
checking setup script
network()
chain()
setupStep(90)
FAIL: Something is wrong. There is no value for network in /home/admin/raspiblitz.info.
Should be at least default value. EXIT
~

The above mentioned file looks like this:

~bash
$ cat /home/admin/raspiblitz.info
state=ready
message='waiting login'
network=
chain=
setupStep=90
~

[raumi75]

I changed it to be

~
network=bitcoin
chain=main
~

and ran ./10setupBlitz.sh again. Not sure if that was smart. It ran lots of configurations and asked me for the node name, again, then rebooted. Now I'm at the same point: Lightning Filtering Blockchain.

Should I just be more patient?

[raumi75]

The background is that lnd is not starting up. The lnd service keeps restarting.

This is the log:

~~~
2019-02-11 02:30:57.364 [INF] LTND: Version: 0.5.1-beta commit=, build=production, logging=default
2019-02-11 02:30:57.364 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-02-11 02:30:57.366 [INF] LTND: Shutdown complete
panic: invalid page type: 15274: 10

goroutine 1 [running]:
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Cursor).search(0x2835c28, 0x1260538, 0x8, 0x8, 0x3baa, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/cursor.go:256 +0x2c4
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Cursor).seek(0x2835c28, 0x1260538, 0x8, 0x8, 0x0, 0x0, 0x0, 0x53301, 0x0, 0x7099c, ...)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/cursor.go:159 +0xa0
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Bucket).Bucket(0x262e10c, 0x1260538, 0x8, 0x8, 0x25eca00)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/bucket.go:105 +0xa8
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Tx).Bucket(0x262e100, 0x1260538, 0x8, 0x8, 0x262e100)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/tx.go:101 +0x3c
github.com/lightningnetwork/lnd/channeldb.fetchMeta(0x248e140, 0x262e100, 0x0, 0x2835c8c)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:42 +0x40
github.com/lightningnetwork/lnd/channeldb.(DB).FetchMeta.func1(0x262e100, 0xb16fec, 0x262e100)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:29 +0x24
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(DB).View(0x2636000, 0x2835cc0, 0x0, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/db.go:699 +0x84
github.com/lightningnetwork/lnd/channeldb.(DB).FetchMeta(0x252a060, 0x0, 0x5eb26000, 0x213f00, 0x8)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:28 +0x58
github.com/lightningnetwork/lnd/channeldb.(DB).syncVersions(0x252a060, 0x13253c0, 0x8, 0x8, 0x2636000, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/db.go:768 +0x24
github.com/lightningnetwork/lnd/channeldb.Open(0x24a0620, 0x1f, 0x3, 0x24a0620, 0x1f)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/db.go:132 +0x120
main.lndMain(0x0, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/lnd.go:162 +0x354
main.main()
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/lnd.go:449 +0x14

~~~

[rootzoll]

Loosing the config values should be fixed for next release. But also one of my test machines is stuck at that point. Will put this on the issue list for 1.0 release and check over the next days.

[raumi75]

Any idea what's behind this "panic"?

I don't know if this is relevant, but prior to the unsuccessful reboot, I had a "Read-error on swap device", which rendered my raspi inaccessible.

[openoms]

I was stuck on this with multiple builds. The problem is that the publicIP= line in raspiblitz.conf is not being filled in by _bootstrap.sh during the first run.
The lnd.service starts lnd with ExecStart=/usr/local/bin/lnd --externalip=${publicIP} - it expects a publicIP and it breaks if it is not there.
You can check if it is the case with sudo systemctl status lnd.

Running sudo ./home/admin/_bootstrap.sh solved the problem for me or you can edit the raspiblitz.conf manually to fill the external IP.
To continue the setup either restart with sudo shutdown -r now or run ./00mainMenu.sh.

This is only an issue on the first run. I was experimenting to change the bootstrap.service from Type=oneshot to simple and introduced a 5 sec wait when looking for the IP the first time. Cannot confirm yet that these have worked. Will need to build from scratch again to test.

[rootzoll]

@openoms much thanks for your analysis. Would love to think about together how to best solve this.

I think keeping the service type to "oneshot" would be best to ensure that boostrap has completed before other servcies (bitcoin/lnd/background) start. But it should not leave the publicIP empty then. This is the code at the moement in the boostrap script:

  freshPublicIP=$(curl -s http://v4.ipv6-test.com/api/myip.php)
  if [ ${#freshPublicIP} -eq 0 ]; then
   echo "WARNING: Was not able to determine external IP on startup." >> $logFile
  else

One solution I like feedback on would be:
If no public IP can be determined and no old value is available, maybe just set "placeholder" like the local IP or a 100.64.0.1. Once the background service script can detect a new publicIP it will update that and on next restart it will use that one. Not perfect, but at least might prevent getting stuck.

[openoms]

I agree that placing the LAN address until the next check would work. Already seen that happening to a Casa node behind a VPN. On 1ml.com the first IP being advertised was their LAN IP.
Just cannot let the line to be empty because that is what is stopping LND.
Can we try some other message, which is not IP format? Like 'publicIP=bootstrapping' or similar?

[rootzoll]

I think there is some IP address validation with LND and a custom string might break stuff - so close before 1.0 release I want to play it safe here.

Also on the first start I will try later in the process to determine the publicIP (when the raspiblitz.conf gets first time written to the HDD in 40initHD.sh) ... so chances should be good to have something valid at that point to work with - making using the localIP just a fallback in edge cases.

[openoms]

This won`t write it to the config:
freshPublicIP="${localIP}"
instead I wrote:
sed -i "s/^publicIP=.*/publicIP=${localIP}/g" ${configFile}

[rootzoll]

Let me explain my code logic - not sure if thats good code or not, but makes sense to me and should work - here is why:

When it got an empty freshPublicIP it will replace it (not writing to conf file, just replacing the variable value) with the localIP but ONLY when there was no publicIP set before. If there was a value it will not replace and use the old one - this way if the v4.ipv6-test.com is down it will work with old values until its up again.

Then below that there is the old code that will write the value of freshPublicIP to the config file if it snot empty. It has even some more logic to create, replace and remove double entries - so instead changing the writing to file in all that cases - I just added above a replacing the freshPublicIP if needed.

But will run tests :) Let me know if you still find some flaw in the code - four eyes always better then two. Much thanks.

[openoms]

That works a treat, I have tried :). Thank you for explaining.
I thought that changing the variable within the if statement does not change the global variable outside of the if statement, but it is clearly not how it works in bash.
The issue is sorted, will confirm with a working node soon.

[raumi75]

My RaspiBlitz is not stuck because of a missing externalip. I can start lnd manually and it crashes right away:

~~~ bash
admin@raumiblitz:~ $ sudo -i
root@raumiblitz:~ $ su bitcoin
bitcoin@raumiblitz:~ $ /usr/local/bin/lnd --externalip=(does not belong on GitHub)
2019-02-13 01:04:20.315 [INF] LTND: Version: 0.5.1-beta commit=, build=production, logging=default
2019-02-13 01:04:20.316 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-02-13 01:04:20.318 [INF] LTND: Shutdown complete
panic: invalid page type: 15274: 10

goroutine 1 [running]:
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Cursor).search(0x3095c28, 0x1260538, 0x8, 0x8, 0x3baa, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/cursor.go:256 +0x2c4
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Cursor).seek(0x3095c28, 0x1260538, 0x8, 0x8, 0x0, 0x0, 0x0, 0x53301, 0x0, 0x7099c, ...)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/cursor.go:159 +0xa0
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Bucket).Bucket(0x2d6028c, 0x1260538, 0x8, 0x8, 0x2da4680)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/bucket.go:105 +0xa8
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(Tx).Bucket(0x2d60280, 0x1260538, 0x8, 0x8, 0x2d60280)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/tx.go:101 +0x3c
github.com/lightningnetwork/lnd/channeldb.fetchMeta(0x2daad68, 0x2d60280, 0x0, 0x3095c8c)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:42 +0x40
github.com/lightningnetwork/lnd/channeldb.(DB).FetchMeta.func1(0x2d60280, 0xb16fec, 0x2d60280)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:29 +0x24
github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt.(DB).View(0x3098140, 0x3095cc0, 0x0, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/vendor/github.com/coreos/bbolt/db.go:699 +0x84
github.com/lightningnetwork/lnd/channeldb.(DB).FetchMeta(0x2d14fd0, 0x0, 0x5eb8b000, 0x213f00, 0x8)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:28 +0x58
github.com/lightningnetwork/lnd/channeldb.(DB).syncVersions(0x2d14fd0, 0x13253c0, 0x8, 0x8, 0x3098140, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/db.go:768 +0x24
github.com/lightningnetwork/lnd/channeldb.Open(0x2d085d0, 0x25, 0x3, 0x2d085d0, 0x25)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/db.go:132 +0x120
main.lndMain(0x0, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/lnd.go:162 +0x354
main.main()
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/lnd.go:449 +0x14
~~~

Any tips on how to backup my lightning data and start over? I have like 30 Euro in lightning. Nothing to lose sleep over, but too much to write off. Can I just mv my /mnt/hdd/lnd folder and have setup create a new one?

[rootzoll]

@raumi75 thanks fir reporting. the logs dont give me a good clue here. To start fresh seems like a good idea - I would recommend making a fill backup copy of the /mnt/hdd/lnd dir and then when you finished setting up a new node - you stop lnd and replace the lnd folder with the backup (make sure to have it owned by bitcoin user) .. see here: https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#2-lnd-channel-state-backup

Before you start fresh - would you like to test the v1.0 build? I can post a preview link by evening. It has lnd-0.52 .. maybe that fixes some stuff also. I did test the backup method mentioned above with a change from lnd 0.51 to 0.52 and worked.

[ln3r]

Tragically enough I now have the same issue and it does not seem to be related to the localIP config. After an unexpected shutdown (power went off on my building), my node is stuck at filtering. Could it be related to a corrupted blockchain? It might have occurred because of the sudden shutdown I guess..

*** RASPIBLITZ LOGS ***
blitzversion: 0.99
chainnetwork: bitcoin / main
 03:51:09 up 51 min,  2 users,  load average: 0.23, 0.24, 0.38

*** CHAINNETWORK SYSTEMD STATUS ***
● bitcoind.service - Bitcoin daemon
   Loaded: loaded (/etc/systemd/system/bitcoind.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-02-13 03:00:06 GMT; 51min ago
  Process: 1042 ExecStart=/usr/local/bin/bitcoind -daemon -conf=/home/bitcoin/.bitcoin/bitcoin.conf -pid=/home/bitcoin/.bitcoin/bitcoind.pid (code=exited, status=0/SUCCESS)
 Main PID: 1060 (bitcoind)
   CGroup: /system.slice/bitcoind.service
           └─1060 /usr/local/bin/bitcoind -daemon -conf=/home/bitcoin/.bitcoin/bitcoin.conf -pid=/home/bitcoin/.bitcoin/bitcoind.pid

Feb 13 03:00:06 RaspiBlitz systemd[1]: Starting Bitcoin daemon...
Feb 13 03:00:06 RaspiBlitz systemd[1]: Started Bitcoin daemon.

*** LAST 20 CHAINNETWORK LOGS ***
2019-02-13T03:02:38Z Loading addresses from DNS seeds (could take a while)
2019-02-13T03:02:39Z New outbound peer connected: version: 70015, blocks=562794, peer=0
2019-02-13T03:02:40Z New outbound peer connected: version: 70015, blocks=562794, peer=1
2019-02-13T03:02:55Z 216 addresses found from DNS seeds
2019-02-13T03:02:55Z dnsseed thread exit
2019-02-13T03:03:12Z UpdateTip: new best=00000000000000000007918dfbb64d3932eecd7f870ecb584db4dbfc78a9b718 height=562794 version=0x20000000 log2_work=90.341194 tx=382381337 date='2019-02-13T02:58:10Z' progress=0.999998 cache=2.1MiB(18681txo) warning='43 of last 100 blocks have unexpected version'
2019-02-13T03:03:19Z New outbound peer connected: version: 70015, blocks=562794, peer=3
2019-02-13T03:03:20Z New outbound peer connected: version: 70015, blocks=562794, peer=4
2019-02-13T03:03:21Z New outbound peer connected: version: 70015, blocks=562794, peer=5
2019-02-13T03:03:37Z New outbound peer connected: version: 70015, blocks=562794, peer=6
2019-02-13T03:03:39Z New outbound peer connected: version: 70015, blocks=562794, peer=7
2019-02-13T03:03:39Z New outbound peer connected: version: 70015, blocks=562794, peer=8
2019-02-13T03:07:30Z Pre-allocating up to position 0xe00000 in rev01526.dat
2019-02-13T03:07:30Z UpdateTip: new best=0000000000000000001cbe9f8cb229cb6d74d42c8686bdef863cfc0186acbdf3 height=562795 version=0x20c00000 log2_work=90.341218 tx=382382983 date='2019-02-13T03:05:42Z' progress=0.999999 cache=4.2MiB(37116txo) warning='44 of last 100 blocks have unexpected version'
2019-02-13T03:14:38Z UpdateTip: new best=0000000000000000000192f09e0a395b2fbf2fdbcef810ca1e7ffea15917aec6 height=562796 version=0x20000000 log2_work=90.341241 tx=382385873 date='2019-02-13T03:13:29Z' progress=1.000000 cache=8.2MiB(72679txo) warning='44 of last 100 blocks have unexpected version'
2019-02-13T03:17:39Z UpdateTip: new best=0000000000000000000f54c952b9b58d0d0f3261cf54873a54291b351ed0730c height=562797 version=0x20c00000 log2_work=90.341265 tx=382388873 date='2019-02-13T03:15:19Z' progress=0.999999 cache=10.2MiB(91798txo) warning='45 of last 100 blocks have unexpected version'
2019-02-13T03:18:44Z Imported mempool transactions from disk: 21452 succeeded, 1054 failed, 0 expired, 0 already there
2019-02-13T03:33:40Z UpdateTip: new best=00000000000000000017d071337ce503def354db6a59a07f1e77aba97de78cae height=562798 version=0x20c00000 log2_work=90.341289 tx=382391441 date='2019-02-13T03:33:26Z' progress=1.000000 cache=11.3MiB(101916txo) warning='46 of last 100 blocks have unexpected version'
2019-02-13T03:40:45Z UpdateTip: new best=00000000000000000025318809355c1a7285aac3e87216439c3e3f73320b7078 height=562799 version=0x20c00000 log2_work=90.341313 tx=382393949 date='2019-02-13T03:40:20Z' progress=1.000000 cache=11.8MiB(106518txo) warning='47 of last 100 blocks have unexpected version'
2019-02-13T03:50:05Z UpdateTip: new best=000000000000000000086f69971a7ecb917c46d7f255eed578d93917aac691e1 height=562800 version=0x20800000 log2_work=90.341337 tx=382396451 date='2019-02-13T03:49:24Z' progress=1.000000 cache=13.2MiB(115441txo) warning='47 of last 100 blocks have unexpected version'

*** LND SYSTEMD STATUS ***
● lnd.service - LND Lightning Daemon
   Loaded: loaded (/etc/systemd/system/lnd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-02-13 03:48:28 GMT; 2min 40s ago
 Main PID: 1859 (lnd)
   CGroup: /system.slice/lnd.service
           └─1859 /usr/local/bin/lnd --externalip=

Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.066 [INF] RPCS: password gRPC proxy started at [::]:8080
Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.066 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to cre… unlock it.
Hint: Some lines were ellipsized, use -l to show in full.

*** LAST 20 LND LOGS ***
-- Logs begin at Wed 2019-02-13 02:59:11 GMT, end at Wed 2019-02-13 03:51:09 GMT. --
Feb 13 03:47:21 RaspiBlitz lnd[713]: 2019-02-13 03:47:21.548 [DBG] LNWL: Using minimum fee rate of 253 sat/kw
Feb 13 03:47:28 RaspiBlitz lnd[713]: 2019-02-13 03:47:28.057 [INF] LNWL: The wallet has been unlocked without a time limit
Feb 13 03:47:28 RaspiBlitz lnd[713]: 2019-02-13 03:47:28.069 [INF] LTND: LightningWallet opened
Feb 13 03:47:28 RaspiBlitz lnd[713]: 2019-02-13 03:47:28.069 [DBG] LNWL: Birthday block has already been verified: height=562181, hash=00000000000000000027f442923a648e30e04708134bbb1e0ff8df507c6f23e3
Feb 13 03:47:28 RaspiBlitz lnd[713]: 2019-02-13 03:47:28.181 [INF] LNWL: Started rescan from block 00000000000000000024c419138a04217ebb2e7f0cac9b23c6cc110bb0fc4301 (height 562792) for 1 address
Feb 13 03:47:28 RaspiBlitz lnd[713]: 2019-02-13 03:47:28.187 [INF] HSWC: Restoring in-memory circuit state from disk
Feb 13 03:47:28 RaspiBlitz lnd[713]: 2019-02-13 03:47:28.188 [INF] LNWL: Starting rescan from block 00000000000000000024c419138a04217ebb2e7f0cac9b23c6cc110bb0fc4301
Feb 13 03:47:28 RaspiBlitz lnd[713]: 2019-02-13 03:47:28.237 [INF] HSWC: Payment circuits loaded: num_pending=0, num_open=0
Feb 13 03:47:28 RaspiBlitz systemd[1]: lnd.service: Main process exited, code=exited, status=1/FAILURE
Feb 13 03:47:28 RaspiBlitz systemd[1]: lnd.service: Unit entered failed state.
Feb 13 03:47:28 RaspiBlitz systemd[1]: lnd.service: Failed with result 'exit-code'.
Feb 13 03:48:28 RaspiBlitz systemd[1]: lnd.service: Service hold-off time over, scheduling restart.
Feb 13 03:48:28 RaspiBlitz systemd[1]: Stopped LND Lightning Daemon.
Feb 13 03:48:28 RaspiBlitz systemd[1]: Started LND Lightning Daemon.
Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.057 [INF] LTND: Version: 0.5.1-beta commit=, build=production, logging=default
Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.058 [INF] LTND: Active chain: Bitcoin (network=mainnet)
Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.058 [INF] CHDB: Checking for schema update: latest_version=7, db_version=7
Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.065 [INF] RPCS: password RPC server listening on [::]:10009
Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.066 [INF] RPCS: password gRPC proxy started at [::]:8080
Feb 13 03:48:29 RaspiBlitz lnd[1859]: 2019-02-13 03:48:29.066 [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.

[rootzoll]

bitcoind is telling in the logs "Imported mempool transactions from disk" --> "1054 failed" .. so this could be related to data corruption on the disk.

Such could stemm from (list incomplete)

• faulty torrent/ftp download
• power outage
• hard shutdown
• undervoltage of power supply

I ordered new power adapters on amazon, to check if they could be better replacements to those on the german shopping list. To rule out that source of error - the HDD could be supplied with a second power source by y-cable.

There is also a research issue about protecting against power outages:
https://github.com/rootzoll/raspiblitz/issues/263

solution could be to download blockchain fresh ... there is no script for that situation yet. But could nbe done by stopping bitcoind+lnd deleting the /mnt/hdd/bitcoin and replace it from a fresh source (SCP copy), than reboot. SCP Copy see: https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#i-have-the-full-blockchain-on-another-computer-how-do-i-copy-it-to-the-raspiblitz

[rootzoll]

I added to the FAQ how to replace a corrupted blockchain by replacing it by SCP from another compter: https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#i-have-the-full-blockchain-on-another-computer-how-do-i-copy-it-to-the-raspiblitz

test results welcome

[ln3r]

I don't have the chain on another computer unfortunately. I think I'll start a fresh instance instead. Are you looking for beta users for v1.0? I'm down to try :)

[rootzoll]

Here is the v1.0 image I am runnig last tests on: wiki.fulmo.org/downloads/raspiblitz-v1.0-2019-02-14.img.zip .. happy on feedback :)

[ln3r]

Awesome, will test and provide feedback :)

How can I prevent data corruption in the future if I have an external HDD and want to shut down the raspiblitz?

[raumi75]

Thank you for the new image. Unfortunately it did not solve my problem.

When loading lnd, I still get this:

~~~
2019-02-14 21:00:29.288 [INF] LTND: Version: 0.5.2-beta commit=v0.5.2-beta, build=production, logging=default
2019-02-14 21:00:29.288 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-02-14 21:00:29.290 [INF] LTND: Shutdown complete
panic: invalid page type: 15274: 10

goroutine 1 [running]:
github.com/coreos/bbolt.(Cursor).search(0x3851c28, 0x1270610, 0x8, 0x8, 0x3baa, 0x0)
/Users/roasbeef/gocode/pkg/mod/github.com/coreos/bbolt@v0.0.0-20180223184059-7ee3ded59d4835e10f3e7d0f7603c42aa5e83820/cursor.go:250 +0x2c4
github.com/coreos/bbolt.(Cursor).seek(0x3851c28, 0x1270610, 0x8, 0x8, 0x0, 0x0, 0x0, 0x53401, 0x0, 0x70ac4, ...)
/Users/roasbeef/gocode/pkg/mod/github.com/coreos/bbolt@v0.0.0-20180223184059-7ee3ded59d4835e10f3e7d0f7603c42aa5e83820/cursor.go:159 +0xa0
github.com/coreos/bbolt.(Bucket).Bucket(0x35e408c, 0x1270610, 0x8, 0x8, 0x3593160)
/Users/roasbeef/gocode/pkg/mod/github.com/coreos/bbolt@v0.0.0-20180223184059-7ee3ded59d4835e10f3e7d0f7603c42aa5e83820/bucket.go:105 +0xa8
github.com/coreos/bbolt.(Tx).Bucket(0x35e4080, 0x1270610, 0x8, 0x8, 0x35e4080)
/Users/roasbeef/gocode/pkg/mod/github.com/coreos/bbolt@v0.0.0-20180223184059-7ee3ded59d4835e10f3e7d0f7603c42aa5e83820/tx.go:101 +0x3c
github.com/lightningnetwork/lnd/channeldb.fetchMeta(0x35dc060, 0x35e4080, 0x0, 0x3851c8c)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:40 +0x40
github.com/lightningnetwork/lnd/channeldb.(DB).FetchMeta.func1(0x35e4080, 0xb4d51c, 0x35e4080)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:27 +0x24
github.com/coreos/bbolt.(DB).View(0x35ee000, 0x3851cc0, 0x0, 0x0)
/Users/roasbeef/gocode/pkg/mod/github.com/coreos/bbolt@v0.0.0-20180223184059-7ee3ded59d4835e10f3e7d0f7603c42aa5e83820/db.go:701 +0x84
github.com/lightningnetwork/lnd/channeldb.(DB).FetchMeta(0x35de050, 0x0, 0x49b100, 0x35ee000, 0x8)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/meta.go:26 +0x58
github.com/lightningnetwork/lnd/channeldb.(DB).syncVersions(0x35de050, 0x13354a0, 0x8, 0x8, 0x35ee000, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/db.go:779 +0x24
github.com/lightningnetwork/lnd/channeldb.Open(0x35ec000, 0x25, 0x3, 0x35ec000, 0x25)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/channeldb/db.go:132 +0x120
main.lndMain(0x0, 0x0)
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/lnd.go:162 +0x354
main.main()
/Users/roasbeef/gocode/src/github.com/lightningnetwork/lnd/lnd.go:449 +0x14
~~~

[rootzoll]

@ln3r in the main menu the "OFF" method is the safest way to do it.

[rootzoll]

@raumi75 thats quite an error stack. When looking at it again, it seems like something is failing in the channel.db - so this could be that there is data corruption on the lnd data part (also) - not on the blockhain data (what seems the source of error with most other such cases).

Not sure if you just can just delete the channel data in the lnd directory and let it build fresh? If you feel experimental, might give it a try or ask about it on the LND dev slack: https://dev.lightning.community

[ln3r]

@rootzoll I'm having build problems with the image from here: wiki.fulmo.org/downloads/raspiblitz-v1.0-2019-02-14.img.zip

I tried downloading it multiple times and tried 2 different SDs in different RPis, but it won't build. Maybe there was a problem with the compression of the file (OSX's archive utility failed and I had to use an alternative one).

[raumi75]

@rootzoll I renamed the channel.db and lnd started. Of course without any channels. Will the peers close the channels now and the funds will be committed to the blockchain eventually?

[rootzoll]

@raumi75 when the peers close the channel is not safe to say - its on their decision.

[rootzoll]

@ln3r thanks for reporting that in. I preperaion of v1.0 release I moved my personal creation pocess of the sd card image to a safer ubuntu/linux based machine - seems like I need to chakc on the zipping part again there - i get the same error when I try to unzip with OSX. But on OSX using "balenaEther" I can flash the zip directly and it runs.

[rootzoll]

OK .. the image building process is unpacking the IMG from .gz file without errors on OSX.

I preperation of v1.0 release I will close this issue now. If there is still any problem, please test of this is still a thing with the v1.0 released image - and if so open a fresh issue. Much thanks.

[kilrau]

This issue is definitely still on - just ran into it and still trying to fix it. It comes up when somewhere during the lnd setup one ctrl+c accidentally or the setup script flow is somehow otherwise interrupted. SSH back in shows that /mnt/hdd/lnd is created but is not complete. Afterwards status page is just stuck at

[kilrau]

I rebooted, and ran script 60finishHDD.sh again - went through the LND setup once more - worked. @rootzoll

[jay653]

@kilrau I have the same issue (Lightning Filtering Blockchain stuck at ? / 565753 blocks).

At first Raspi didnt find some lnd files, so I guessed something went wrong with the lnd setup.

ran script 60finishhdd.sh again but still no progress even after a few hours.

Also the Raspi Autolocks the LND Wallet after a few minutes in "Lightning Filtering Blockchain mode" and asks for my wallet password again.