mirror of https://github.com/hyperledger/besu
Moved known issues into separate file (#751)
Signed-off-by: Madeline <madeline.murray@consensys.net>pull/757/head
parent
1fba712202
commit
8ededd7a35
@ -0,0 +1,68 @@ |
||||
# Known Issues |
||||
|
||||
Details on previously identified known issues are provided below. Details on known issues identfied |
||||
in the current release are provided in the [Changelog](CHANGELOG.md). |
||||
|
||||
Known issues are open issues categorized as [Very High or High impact](https://wiki.hyperledger.org/display/BESU/Defect+Prioritisation+Policy). |
||||
|
||||
## Eth/65 not backwards compatible |
||||
|
||||
The `eth/65` change is not [backwards compatible](https://github.com/hyperledger/besu/issues/723). |
||||
This has the following impact: |
||||
* In a private network, nodes using the 1.4.3 client cannot interact with nodes using 1.4.2 or earlier |
||||
clients. |
||||
* On mainnet, synchronizing eventually stalls. |
||||
|
||||
A fix for this issue is being actively worked on. |
||||
|
||||
## Error full syncing with pruning |
||||
|
||||
- Error syncing with mainnet on Besu 1.3.7 node - MerkleTrieException [\#580](https://github.com/hyperledger/besu/issues/580) |
||||
The associated error is `Unable to load trie node value for hash` and is caused by the combination of |
||||
full sync and pruning. |
||||
|
||||
Workarounds: |
||||
1. Explicitly disable pruning using `--pruning-enabled=false` when using fast sync. |
||||
2. If the `MerkleTrieException` occurs, delete the database and resync. |
||||
|
||||
A fix for this issue is being actively worked on. |
||||
|
||||
## Fast sync when running Besu on cloud providers |
||||
|
||||
A known [RocksDB issue](https://github.com/facebook/rocksdb/issues/6435) causes fast sync to fail |
||||
when running Besu on certain cloud providers. The following errors is displayed repeatedly: |
||||
|
||||
``` |
||||
... |
||||
EthScheduler-Services-1 (importBlock) | ERROR | PipelineChainDownloader | Chain download failed. Restarting after short delay. |
||||
java.util.concurrent.CompletionException: org.hyperledger.besu.plugin.services.exception.StorageException: org.rocksdb.RocksDBException: block checksum mismatch: |
||||
.... |
||||
``` |
||||
|
||||
This behaviour has been seen on AWS and Digital Ocean. |
||||
|
||||
Workaround -> On AWS, a full restart of the AWS VM is required to restart the fast sync. |
||||
|
||||
Fast sync is not currently supported on Digital Ocean. We are investigating options to |
||||
[add support for fast sync on Digital Ocean](https://github.com/hyperledger/besu/issues/591). |
||||
|
||||
## Fast sync reverting to full sync |
||||
|
||||
In some cases of FastSyncException, fast sync reverts back to a full sync before having reached the |
||||
pivot block. [\#683](https://github.com/hyperledger/besu/issues/683) |
||||
|
||||
Workaround -> To re-attempt fast syncing rather than continue full syncing, stop Besu, delete your |
||||
database, and start again. |
||||
|
||||
## Bootnodes must be validators when using onchain permissioning |
||||
|
||||
- Onchain permissioning nodes can't peer when using a non-validator bootnode [\#528](https://github.com/hyperledger/besu/issues/528) |
||||
|
||||
Workaround -> When using onchain permissioning, ensure bootnodes are also validators. |
||||
|
||||
## Privacy users with private transactions created using v1.3.4 or earlier |
||||
|
||||
A critical issue for privacy users with private transactions created using Hyperledger Besu v1.3.4 |
||||
or earlier has been identified. If you have a network with private transaction created using v1.3.4 |
||||
or earlier, please read the following and take the appropriate steps: |
||||
https://wiki.hyperledger.org/display/BESU/Critical+Issue+for+Privacy+Users |
Loading…
Reference in new issue