Start9 Support: Bitcoin Core crashes, filesystem corruption, and backup failures

Hello Start9 Support,

I’m experiencing several serious issues with my Start9 Pure server and would appreciate help diagnosing the underlying problem before attempting further repairs or rebuilding my Bitcoin node.

The server was previously repaired by Start9, but I’d like to focus on the current problems.

1. Bitcoin Knots and Fulcrum indexing problems

Until recently, I was running Bitcoin Knots (pre-RDTS), which was fully synchronized, with RPC operational and blockchain indexes up to date.

However, Fulcrum 2.1.2:1 became stuck indexing at approximately block 127,813 and made no meaningful progress for several days.

We examined the Fulcrum logs and attempted troubleshooting, but the indexing problem remained unresolved.

2. Switch to Bitcoin Core

I subsequently switched from Bitcoin Knots to Bitcoin Core 31.1:18. Knots is no longer installed.

Bitcoin Core initially started processing block headers, but the dashboard reported:

  • Blockchain Sync: Incorrect locale information provided

  • RPC: bitcoind daemon crashed

  • I2P startup and connection errors

I disabled I2P through Bitcoin Core’s Peer Settings. The dashboard confirmed I2P was disabled, but Bitcoin Core continued to crash.

3. Bitcoin Core reports corrupted blockchain data

The Bitcoin Core logs show:

Corrupt block found indicating potential hardware failure

bad-txnmrklroot, hashMerkleRoot mismatch

Failed to connect best block

bitcoind exited with code 1

The chainstate was approximately at block height 125,676 when validation failed.

Bitcoin Core is currently stopped. I have not attempted another reindex or deleted its data.

4. Extensive kernel errors and application crashes

StartOS kernel logs show repeated errors:

SQUASHFS error: xz decompression failed, data probably corrupt

SQUASHFS error: Failed to read block 0x469078: -5

These appeared repeatedly over several minutes.

The logs also contain numerous segmentation faults involving applications and processes, including Bash, health-check scripts, and Bitcoin-related processes.

I’m concerned that the problems may extend beyond the Bitcoin installation and involve the server’s storage, memory, or filesystem integrity.

5. Unexpectedly low storage usage

The StartOS Metrics dashboard reports:

  • Total capacity: 3,977.34 GB

  • Used: 92.29 GB

  • Available: 3,885.05 GB

This is surprising because Bitcoin Knots previously maintained a fully synchronized archival blockchain.

I don’t know whether the blockchain data was removed during the switch to Core or whether another issue is involved.

6. Unable to create a backup

Before attempting repairs, I tried creating a StartOS backup to a shared folder on my Mac.

The SMB share is named START9BACKUP, hosted at 192.168.8.159.

We verified that SMB sharing is enabled, the share is advertised and accessible from the Mac, permissions allow writing, and the Mac firewall is disabled.

However, StartOS repeatedly fails to mount the share.

The kernel logs show:

CIFS: Attempting to mount //192.168.8.159/START9BACKUP

CIFS: VFS: cifs_mount failed w/return code = -2

The StartOS interface reports:

mount error(2): No such file or directory

We tried both the hostname and IP address and different path formats, without success.

My most recent recorded StartOS backup is from January 13, 2026. I’d like to create a current backup before doing anything that could affect Core Lightning, Vaultwarden, or other service data.

7. Current status and requested assistance

Bitcoin Core is stopped. I have not reindexed, rebuilt, uninstalled, or erased anything since discovering the corruption.

I’d appreciate guidance on:

  1. Diagnosing the underlying problem: Do the SquashFS errors, segmentation faults, and corrupted Bitcoin block suggest an SSD, RAM, filesystem, or software issue?

  2. Checking hardware health: What diagnostics can we safely perform?

  3. Resolving the backup problem: How can I create a reliable backup before proceeding?

  4. Understanding the missing blockchain data: Why does the server report only 92 GB used when I previously had a fully synchronized archival node?

  5. Restoring services: Once the underlying problem is identified, what is the safest way to get Bitcoin Core and Fulcrum operational again without jeopardizing Core Lightning or other service data?

I’m reluctant to undertake another lengthy blockchain synchronization until we know the server is functioning reliably.

I can provide the complete Bitcoin Core and kernel logs and relevant screenshots.

Thank you.

I think it may be much more efficient to go through troubleshooting steps live, in real time. I’d strongly recommend for you to visit out live support server: