Hi guys.
Could it be for I upgraded to 0.43.0? Prior to that webui had shown geolocation a ok. I do not see any errors/warnings in logs.
Any thoughts are much appreciated. Thanks, L.
Most likely just the geoip dataset being refetched.
WebUI ships no geoip database. It looks up each peer IP in a dataset stored on IPFS, pulling only the blocks it needs through your node’s gateway. The WebUI in 0.43 points at a newer dataset than older versions did, so none of the blocks your node already had are the ones it now asks for. They have to come from the network again, and the map fills in as they arrive. If the node is online and connected to the main swarm, just give it some time.
If the node runs in a private network, those blocks may never arrive and the map stays empty. Prefetch the dataset on a node that can reach the public network and carry it over:
# on the connected node
ipfs dag export bafyreihwb2rt2kfkzvf3mxgfzzqqbq3ea4bgzwfy5cxz6phdlu3ch55gyq > geoip.car
# on the isolated node
ipfs dag import geoip.car
ipfs dag stat <cid> does the same walk if you only need to warm a node that is already connected.
The root CID is defined here: ipfs-geoip/src/lookup.js at ade9728a5d52066d743e38e53d03d9b5f446700e · ipfs-shipyard/ipfs-geoip · GitHub
Thanks. I think there might be something broken in my setup, data I think.
When I try to export & import command results in errors. Also logs have:
2026-09-21T08:54:14.745Z ERROR provider node/provider.go:971 error closing provider during shutdown{"error": "WAN provider: leveldb/table: corruption on data-block (pos=357418): checksum mismatch, want=0xe1a1f9c2 got=0xefd922a6 [file=2732040.ldb]"}
2026-09-21T08:54:14.893Z ERROR core core/builder.go:110 failure on stop: committing batch to datastore at /: leveldb/table: corruption on data-block (pos=357418): checksum mismatch, want=0xe1a1f9c2 got=0xefd922a6 [file=2732040.ldb]
committing batch to datastore at /: leveldb/table: corruption on data-block (pos=357418): checksum mismatch, want=0xe1a1f9c2 got=0xefd922a6 [file=2732040.ldb]; closing datastore at /: leveldb/table: corruption on data-block (pos=357418): checksum mismatch, want=0xe1a1f9c2 got=0xefd922a6 [file=2732040.ldb]
2026-09-21T08:54:14.894Z ERROR core core/builder.go:127 failure on stop: committing batch to datastore at /: leveldb/table: corruption on data-block (pos=357418): checksum mismatch, want=0xe1a1f9c2 got=0xefd922a6 [file=2732040.ldb]
committing batch to datastore at /: leveldb/table: corruption on data-block (pos=357418): checksum mismatch, want=0xe1a1f9c2 got=0xefd922a6 [file=2732040.ldb]; closing datastore at /: leveldb/table: corruption on data-block (pos=357418): checksum mismatch, want=0xe1a1f9c2 got=0xefd922a6 [file=2732040.ldb]
In case it is data corruptions - is it possible to clean up broken bit or all data - as opposed to complete container destruction?
Yes, you can try to salvage this. It looks like a dying disk though (leveldb checksum errors mean bytes changed on disk), so check it with smartctl first.
The broken bit is $IPFS_PATH/datastore/ (leveldb): pins, MFS root, provider records. Your data is in $IPFS_PATH/blocks/ and is probably fine. ipfs repo verify --heal only repairs blocks/, so you can run it as a precaution, but it will not help with the leveldb failure.
Try: stop the daemon, save pins and MFS root, drop the broken leveldb, restore:
ipfs shutdown
ipfs --offline pin ls --type=recursive -q > pins.txt
ipfs --offline files stat / | head -1 > mfs-root.txt
mv $IPFS_PATH/datastore $IPFS_PATH/datastore.broken
xargs -n1 ipfs --offline pin add < pins.txt
ipfs --offline files chroot --confirm $(cat mfs-root.txt)
ipfs daemon
What happens next depends on the drive:
- If this was a one-off, the above restores normal operation. Run a full drive diagnostic anyway, to know whether it is safe to keep using.
- If the first two commands fail on the corrupt block, you lose only the pin list;
blocks/survives. Do not runipfs repo gcuntil pins are back, or until you have re-pinned the data on a fresh node on a different drive.
I think there might more “serious” issue and an easy one to reproduce - I pulled the image - I spun up a new, from scratch, container, gave it ~48 hours and no geo-locations from peers.