Subnet node fails to launch RPC

[PinkFromTheFuture]

Describe the bug
The RPC fails to start due to failing to verify genesis: invalid network upgrades: Durango fork block timestamp (0) must be greater than or equal to 1707840000

To Reproduce
When following the normal deployment, using version v1.11.4-rc.0,

right after adding a validator to the chain, and restarting the node.

Never upgraded anything, directly created the subnet from v1.11.4-rc.0

Yet, it results in the following error:

Mar 27 05:44:46 avalanche-test-validator-0 avalanchego[16374]: [03-27|05:44:46.328] ERROR chains/manager.go:331 error creating chain {"subnetID": "27yC2Sx7R3cVMvdnvqmgWyaoHPtAkXiVvwFbhJhyuX7CRELMPd", "chainID": "j8yx5vxApPXKQj2xD1dLcXLz9sbnh5XZCHNb4FkgnFVFt83aS", "chainAlias": "j8yx5vxApPXKQj2xD1dLcXLz9sbnh5XZCHNb4FkgnFVFt83aS", "vmID": "e3tkfSJivi8bWmjaSQAcfZU8uejYoTcS4uwSgyed85txHLusr", "error": "error while creating new snowman vm rpc error: code = Unknown desc = failed to verify genesis: invalid network upgrades: Durango fork block timestamp (0) must be greater than or equal to 1707840000"}

Basically the RPC is not working.

The node is boostrapped, and the validator should be online on the newly created fuji subnet.

Expected behavior
The RPC should start and listen on it's respective port.

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
If applicable, please include the relevant logs that indicate a problem and/or the log directory of your node. By default, this can be found at ~/.avalanchego/logs/.

Operating System
Rocky Linux 9 (Red Hat based)

Additional context

A fix was suggested:

skip-upgrade-check (bool)
If set to true, the chain will skip verifying that all expected network upgrades have taken place before the last accepted block on startup. This allows node operators to recover if their node has accepted blocks after a network upgrade with a version of the code prior to the upgrade. Defaults to false.

Arguably skip-upgrade-check should remain false, however this workaround did not work.

here is an extract from my genesis.json:

{
  "config": {
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "durangoTimestamp": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "homesteadBlock": 0,
    "istanbulBlock": 0,
    "muirGlacierBlock": 0,
    "petersburgBlock": 0,
    "subnetEVMTimestamp": 0,
    "warpConfig": {
      "blockTimestamp": 1711482151,
      "quorumNumerator": 67
    }
  },
  "difficulty": "0x0",
  "extraData": "0x",
  "gasLimit": "0x7a1200",
  "gasUsed": "0x0",
  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "nonce": "0x0",
  "number": "0x0",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "timestamp": "0x0"
}

[ceyonur]

Thank you for reporting this.
This seems to be an subnet-evm issue. With Subnet-EVM v0.6.3 we have introduced reschedulable network upgrades. Network upgrades can now rescheduled to a later time than their default value (mainnet/fuji activations). Your genesis has an explicit durango timestamp set to 0 (which is before the default Durango timestamp), so it becomes an invalid genesis. We will put up a fix addressing this issue.

For now you can either :

• downgrade to Subnet-EVM v0.6.2 and keep using your chain
• use subnet-evm v0.6.3 and recreate the chain without an explicit value to durangoTimestamp (just omit)
• use subnet-evm v0.6.3 and issue an coordinated upgrade to reschedule it back to 1707840000 via https://docs.avax.network/build/subnet/upgrade/customize-a-subnet#network-upgrades-rescheduling-mandatory-network-upgrades

[PinkFromTheFuture]

Thanks for the response!

A piece of information: I didn't really set the value 0 in the genesis.json, it was done automatically during the subnet creation process.

downgrade to Subnet-EVM v0.6.2 and keep using your chain

How?

use subnet-evm v0.6.3 and recreate the chain without an explicit value to durangoTimestamp (just omit)

this does not work. when running
avalanche subnet deploy
it says
"Error: failed to validate SubnetEVM genesis format"

use subnet-evm v0.6.3 and issue an coordinated upgrade to reschedule it back to 1707840000 via https://docs.avax.network/build/subnet/upgrade/customize-a-subnet#network-upgrades-rescheduling-mandatory-network-upgrades

I just tried to issue a coordinated upgrade to reschedule it, but maybe I did something wrong?
I created the file upgrade.json in the same subfolder of the .avalanchego where the config.json file is located, with the following contents:

{
  "networkUpgradeOverrides": {
    "durangoTimestamp": 1707840000
  }
}

Then I simply restarted the node but I still observed the exact same error in the logs.

Please note that this is a newly created network, with a single node and validator.

[PinkFromTheFuture]

I made the effort to recreate and deploy a subnet, this time I manually set the durangoTimestamp to 1707840000 after genesis.json was created.

It worked.

[ijonas]

Hey @PinkFromTheFuture

Would you mind providing some more detailed steps on how to fix the issue? I'm stuck in the same spot.
How did you recreate your subnet and set the durangoTimestamp to a non-zero value ?

Many thanks.

[PinkFromTheFuture]

My pleasure!

When you run avalanche subnet create "Name of your subnet"
it will create a genesis.json file somewhere. The default path would be ~/.avalanche-cli/subnets/Name of your subnet/

Then, before executing the next command, which would be avalanche subnet deploy "Name of your subnet"
you should edit the genesis.json file. Look for the line that says

"durangoTimestamp": 0,
and change it to
"durangoTimestamp": 1707840000,

Hope this unblocks you while a fix is not released.

[ijonas]

Thank you @PinkFromTheFuture!

That did the trick.