Next block not supported

Running a full archival node for betanet on a debian 10 instance and discovered this message this morning when I ran goal node status -d /betanet:

Last supported block (10405446) is committed. The next block consensus protocol is not supported. Catchup service is stopped.

Algod output:

admind:~$ algod -v
2.5.5.stable [rel/stable] (commit #304815d0)
go-algorand is licensed with AGPLv3.0
source code available at

Also I was looking at the updating node docs today: Install a Node - Algorand Developer Portal and found the section for DNS Configuration for Betanet. I didn’t realize this needed to be done and never configured the DNSBootstrapID to <network> in the config.json. Will configuring it after the fact make a difference?

Quick answer - you need to upgrade your node to the latest version.
See my answer here : Catchup service is stopped (testnet) - #5 by tsachi.

As for the DNS configuration - the documents are abit behind the codebase. You don’t need to make any modification to the config.json. It would work just as you’d expect it to work out of the box.

Am I not already on the latest version? See my output for algod -v I pasted above. Also when I run apt-get update and apt-get upgrade, I don’t see any updates for algorand or algod.

Also thanks for the tip regarding the DNS configuration.

There is a 2.5.6 for betanet : BetaNet Update: 2.5.6

Given that 2.5.6 is a consensus upgrade, the issue that you’ve ran into is expected.

I don’t know why the update procedure you’ve used did not work.

Hi @harshbaid,

I think that I understand what the issue is. You have configured the updater to give you the latest mainnet binary, and then changed the data directory to point betanet.

While this would not break anything on it’s own, what you’re seeing is quite expected:
the mainnet binaries have not been released yet ( because it’s being tested on betanet as we speak ), and the betanet network have switched to a protocol that is not yet supported by mainnet.

To resolve this issue, I suggest that you’ll uninstall the algorand binaries ( and keep the data directory ), update the installation to have the betanet binaries, and then install it from there.

I see that in the installation instructions,

sudo add-apt-repository "deb stable main"

need to be replaced with the equivalent betanet ones. (I’ll be looking where these are)

1 Like

Yup I was just thinking the same thing. Let me give you a brief overview of my machine as I’m unsure even with the updated repository how I would adapt the fix to my current situation.

Currently running a debian cloud sever with 3 network disks attached:

  • /mainnet
  • /betanet
  • /testnet

I added a genesis.json, config.json, and system.json file to each of the 3 disks and then ran:

goal node start -d /<betanet/testnet/mainnet>

to start 3 algod processes that will update the 3 disks. I guess what you’re saying is I essentially would need to have a separate machine that is running an updated algod process for betanet otherwise there is no way around it?


I’m going to break my answer into three section -

First, the betanet is usually not too far off from the mainnet one. In practice, using the betanet installation for mainnet/testnet would work just fine. The only caveat here is that if some serious issue would be found while it’s being tested on betanet, there could be multiple releases to betanet before a stable build is released to mainnet/testnet.

Second, a simplified approach is to use docker as a container for these ( the actual data directory can be mounted from the host ). I’m not a docker expert, but it’s definitely doable.

Last, while the Debian installation was designed for the most common use case ( where there is only a single version on the system ), the algorand binaries themselves don’t rely on any such premise. You can use the script to deploy the binaries to any directory, allowing you to have any number of different binaries/data directories on your computer. You will need, however, to ensure that the correct binary directory is in your PATH. ( this option might be a good choice for someone who has some background in linux and familiarity with the command line )

Hey @tsachi,

Yeah definitely seems like docker containers are the way to go and just having separate binaries running different instructions. Also it would make failover easier since all I would need to do is spin up a docker container, spin down the other one and then transfer over the disk.

So are you recommending I simply disregard pulling from the package repository and using the update script here:

This feels more brittle than simply doing apt-get upgrade algorand.

The 2.5.6 was just released to mainnet, so I think that upgrading it now would fix the problem… for the short run.

If you can use docker containers, then I think it would be your best solution. Otherwise, the script is also an option.

I agree that running a script might feel more brittle. But you can be rest assured that it’s being tested and maintained regularly.

Gotcha! Thanks for your help!