Attempting to start an ethereum node, getting "Fatal: Consensus not specified. Exiting!!"

[DRichards-JPM-Onyx]

System information

Geth version: geth version 1.9.7-stable, Quorum 2.6 OS & Version: Linux Enterprise Redhat Commit hash : (if develop)

Expected behaviour

Node should start with startup script.

Backstory ie Why i'm using v 2.6: I'm attempting to troubleshoot the migration of a Quorum Network from Quorum version 2.6 (geth 1.9.7) to Quorum 22.7.0.

My host machine is running macOS and I am using SSH to connect to an Linux Redhat EC2 Instance to run my network. On said instance: I've installed Quorum using the binary for version 2.6.0. I've used the latest version of the "quorum-genesis-tool" to generate my "static-nodes.json", "permissioned-nodes.json", and "genesis.json."

I've initialized my node(s) pointing to my data directory with the --datadir flag and used the init command to point to the genesis.json in my data directory.

I've attempting to start my node using what I think are the appropriate flags.

At this point I'm expecting my node to start, but I'm met with a fatal error in my terminal.

"Fatal: Consensus not specified. Exiting!!"

//Code To reproduce listed below

-How I have debug?-

I assumed this might be an issue with the binary of my version of geth, as I had more than one version of geth on my machine as I troubleshot migration. I resolved this. I then assumed that this might be an issue with the genesis.json file generated from the quorum-genesis-tool. The two versions of my genesis.json is listed under steps to reproduce. (there are two versions because I attempted to start the node with each genesis file, and each failed)

Any insight would be greatly appreciated!!!

Actual behaviour

I'm met with a fatal error in my terminal.

Fatal: Consensus not specified. Exiting!!

geth version returns:

Geth Version: 1.9.7-stable Git Commit: 9339be03f9119ee488b05cf087d103da7e68f053 Git Commit Date: 20200504 Quorum Version: 2.6.0 Architecture: amd64 Protocol Versions: [64 63] Network Id: 1337 Go Version: go1.13.10 Operating System: linux GOPATH= GOROOT=/home/travis/.gimme/versions/go1.13.10.linux.amd64

Steps to reproduce the behaviour

I've installed Quorum using the binary for version 2.6.0.

npx quorum-genesis-tool --consensus ibft \ --chainID 1337 --blockperiod 5 \ --requestTimeout 10 --epochLength 30000 \ --difficulty 1 --gasLimit '0xFFFFFF' \ --coinbase '0x0000000000000000000000000000000000000000' \ --validators 5 --members 0 --bootnodes 0 \ --outputPath 'artifacts' \

I've initialized my node(s) pointing to my data directory with the --datadir flag and used the init command to point to the genesis.json in my data directory.

geth —datadir data init data/genesis.json

I've then attempting to start my node with this command (which i assume is appropriate for the version of geth i'm running):

geth --datadir data \ --networkid 1337 \ --nodiscover --verbosity 5 --syncmode full --nousb \ --istanbul.blockperiod 5 --istanbul.requesttimeout 10000 \ --mine --miner.threads 1 --miner.gasprice 0 --emitcheckpoints --rpc \ --rpcaddr 127.0.0.1 --rpcport 22000 \ --rpccorsdomain "*" --rpcvhosts "*" \ --ws --wsapi admin,trace,db,eth,debug,miner,net,shh,txpool,personal,web3,quorum,istanbul \ --wsaddr 127.0.0.1 --wsport 32000 --wsorigins "*" \ --unlock ${ADDRESS} --allow-insecure-unlock \ --password ./data/keystore/accountPassword \ --port 30300

My genesis.json (config section) after seeing a coworker's genesis.json from months prior: I imagine the istanbul section to be the important

"config": { "chainId": 1337, "homesteadBlock": 0, "eip150Block": 0, "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000", "eip155Block": 0, "eip158Block": 0, "byzantiumBlock": 0, "constantinopleBlock": 0, "isQuorum": true, "maxCodeSizeConfig": [ { "block": 0, "size": 64 } ], "txnSizeLimit": 64, "istanbul": { "policy": 0, "epoch": 30000, "ceil2Nby3Block": 0 } },

My genesis.json file before alteration: I imagine the istanbul section to be the important

"config": { "chainId": 1337, "homesteadBlock": 0, "eip150Block": 0, "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000", "eip155Block": 0, "eip158Block": 0, "byzantiumBlock": 0, "constantinopleBlock": 0, "isQuorum": true, "maxCodeSizeConfig": [ { "block": 0, "size": 64 } ], "txnSizeLimit": 64, "ibft": { "policy": 0, "epoch": 30000, "ceil2Nby3Block": 0, "blockperiodseconds": 5 } },

Backtrace

[backtrace]

When submitting logs: please submit them as text and not screenshots.

[baptiste-b-pegasys]

Hi, is it needed to use 2.6?

I can see wsapi, I think it misses the rpcapi --wsapi admin,trace,db,eth,debug,miner,net,shh,txpool,personal,web3,quorum,istanbul

[baptiste-b-pegasys]

Can you try with quorum-examples? https://github.com/ConsenSys/quorum-examples/commit/e7c1b045dab232ddb3d86051c52f728341839a4c

[DRichards-JPM-Onyx]

Thanks: ((baptiste-b-pegasys)

Fix:

Resolved by adjusting the genesis.json.

The config key in the genesis.json needs to be ajust.

Inside of the config key, the quorum genesis tool creates a key to determine consensys.

config.ibft = {
      "policy": 0,
      "epoch": 30000,
      "ceil2Nby3Block": 0,
      "blockperiodseconds": 5
    }

"ibft": { "policy": 0, "epoch": 30000, "ceil2Nby3Block": 0, "blockperiodseconds": 5 }

This needs to be adjusted to:

config.istanbul = { "policy": 0, "epoch": 30000, "ceil2Nby3Block": 0, "blockperiodseconds": 5 }

"istanbul": { "epoch": 30000, "policy": 0, "ceil2Nby3Block": 0 }

[dhavalmp194]

Thanks: ((baptiste-b-pegasys)

Fix:

Resolved by adjusting the genesis.json.

The config key in the genesis.json needs to be ajust.

Inside of the config key, the quorum genesis tool creates a key to determine consensys.

config.ibft = {
      "policy": 0,
      "epoch": 30000,
      "ceil2Nby3Block": 0,
      "blockperiodseconds": 5
    }

"ibft": { "policy": 0, "epoch": 30000, "ceil2Nby3Block": 0, "blockperiodseconds": 5 }

This needs to be adjusted to:

config.istanbul = { "policy": 0, "epoch": 30000, "ceil2Nby3Block": 0, "blockperiodseconds": 5 }

"istanbul": { "epoch": 30000, "policy": 0, "ceil2Nby3Block": 0 }

I tried the given solution but it is working on my side