This topic is created to collect all of the FAQ and issues you cannot solve during the mining process. We’ll gather all issues and post them here after coming up with proper solutions.
Please search under this topic first to find answers related to your questions and try to solve them using the solutions provided.
Do not hesitate to comment below whether the solutions work or not.
Related Issues:
In Progress: /
SOLVED!
pherry exited HeaderHashMismatch
[2021-09-18T04:00:58Z INFO pherry] bridge() exited with result: Err(HeaderHashMismatch)
Update: The latest 09-17 snapshot is perfect and thus don’t need to apply the walkaround.
Solution: Delete the Khala block history in the database
1.Stop the node (keep pruntime)
2.Delete the Khala data directory (Keep Kusama): rm -rf khala-node/chains/khala
3.Restart the node and pherryThe reason of this issue is that in the block data snapshot from the bittorrent file, the data of Khala is damaged, but the data of Kusama can still be used. The speed of synchronizing Khala after deleting the snapshot is relatively fast.
Pherry reported an error “Could not decode RuntimeMetadata::V9.0/10.0/…”
Could not decode `RuntimeMetadata::V9.0`
Decoding is not supported
Solution: Wait until the Kusama node is synchronized
The reason for this issue is that the Kusama node is still an old block and is not synchronized well. When pherry starts, it will connect to the Kusama node. The first operation when connecting is to parse the metadata. Metadata is highly bound to the block. Currently, we only support v13, which is the latest version. If the Kusama node is still stuck at 2020 or even 2019, there is a high probability that the metadata retrieved is too old. Therefore, we recommend checking the Kusama block height of the Khala node first when encountering this problem.
Check method: upgrade the script, the latest script will display the height of Kusama. Or you can check the node log, observe the Best height displayed in the [Relaychain] line, and compare it with the latest height on the Kusama block explorer.
Pherry exits pruntime log error bad justification for header
Situation: Pherry exited with an error during synchronization. Check the pruntime log and found the last few logs contain the following information:
[ERROR phactory::prpc_service] Rpc error: AppError("bad justification for header: invalid commit in grandpa justification")
Solution: Update pherry docker image
This issue is caused by the bad pherry version shipped with the solo mining script before the launch day. The problem was fixed before the launch but you may not notice the update.
pRuntime exited with "memory allocation of X bytes failed"
You may get similar error around or after parachain block 400829:
[INFO phactory::prpc_service] Dispatching request: PhactoryAPI.SyncHeader
memory allocation of 74349772 bytes failed
Solution: Update the solo mining script if you are using it.
The new solo mining script added --fetch-blocks=512 to pherry. So it will reduce the memory usage in syncing process. If you are building your own stack, you can consider to limit --fetch-blocks to 512 as well. In the future we will adjust the memory layout to optimize it better.
Khala or Kusama block stuck forever
The Khala node may get stuck at some block height (usually between 8M and 9M relay chain block).
Solution:
- Upgrade to the latest khala node docker image. The problem was already fixed in a new release.
- Optionally, you can try to download the blockchain snapshot (17/09).
Root cause: Kusama Node Fails to Sync Beyond 8949248 · Issue #3778 · paritytech/polkadot · GitHub
pherry syncing too slow
pherry may sync as slow as around 10 blocks per second. However with the performance tweak, it should run at 100 blk/s speed.
Solution: Upgrade to the latest solo mining script (this time a full reinstall of the script and the SGX driver is required).
If you are a power user, you can try to add these environment variables to your docker container:
PARACHAIN_EXTRA_ARGS='--state-cache-size 671088640 --db-cache 2048 --max-runtime-instances 16'
RELAYCHAIN_EXTRA_ARGS='--state-cache-size 671088640 --db-cache 2048 --max-runtime-instances 16'
pRuntime crash due to insufficient memory of SGX
Situation: Solo script, when synced to about 900 million or more Kusama height, memory becomes insufficient, pRuntime exits, and “memory allocation of xxxx bytes failed” appears.
Solution: A new version of pRuntime was published on docker hub (9/30)
Follow the step below to update
sudo phala update
sudo phala start
if your current solo mining script is running without problem, you don’t have to run this update.
Tracking Issue: https://github.com/Phala-Network/phala-blockchain/issues/504
