AesonException "Error in $: key \"AlonzoGenesisFile\" not found"

I am using pre-built binary from release 1.27.0. And trying to setup a node. But the node is stuck at:

(InvalidBlock (At (Block {blockPointSlot = SlotNo 17020941, blockPointHash = 448a53bfbb7aa2671d426e01c6a5e7ade16ab14af8d18417aa8b73c3a000397d})

At first it looked like the same issue as reported/discussed here. But when I tried various suggestions, especially the one by @erikd, I get the following error on terminal:

AesonException "Error in $: key \"AlonzoGenesisFile\" not found"

cardano-node: Aeson exception:
Error in $: key "AlonzoGenesisFile" not found

I am using this command to run the node (ip-hidden):

cardano-node run --topology mainnet-topology.json --database-path db --socket-path db/node.socket --host-addr <my-public-ip> --port 3001 --config mainnet-config.json

I have copied all the configuration files from the tar.gz file from the github release tag 1.27.0.

Thanks for all help.

How about using Docker like this …

docker run --detach \
    --name=relay \
    -p 3001:3001 \
    -v node-data:/opt/cardano/data \
    nessusio/cardano-node run    

… you wouldn’t have fine grained config issues like that

I can try that. But I just want to understand what is happening underneath. And BTW why aren’t you suggesting the official docker image inputoutput/cardano-node?

What is likely happening is that you use code that already expects alonzo config, but you don’t provide the associated keys. Here is a diff of the config.

The nessus-cardano project is an incubator for upstream Docker stuff, which contains various bug fixes, supports topology updates, graceful shutdown and gLiveView. The associated tools have leader log built in. For some folks most important of all, it also supports arm64 - so you can run it on a RaspberryPi4 if you like.

Much of that has now found its way into the upstream codebase, but isn’t released yet. In future, there will hopefully be no need to talk about another docker image other than the one provided by inputoutput, but we aren’t quite there yet.

So, if I want to run this without docker, then should I try the previous version i.e. the latest from 1.26.x. Is this okay for production?

I can only recommend you what I already did. True, many folks use lots of manual steps or various scripts that aim to automate the former, but that is something that I personally wouldn’t want to do.

What might have happened is that you used the download link from here, which points to the “latest” build. It is the latest build of whatever happens to be HEAD of the master branch - it is not the build of the latest tag.

Unfortunately, I don’t even know if there is an easy way to get the pre-built binaries from the latest release. If you don’t find that, you may need to build the 1.27.0 tag from source. That will fix your Alonzo config issue.

IMHO, it is quite confusing that master produces a binary with version 1.27.0, which doesn’t correspond to the 1.27.0 tag.

1 Like

Its here …

as described in …

1 Like

Thanks for this. Finally, I did exactly this and this fixed the issue. I
cloned the git repository and then checked-out tag 1.27.0 into a new
branch. And the followed build instructions.

This worked. I picked configuration files also from the same checked-out
snapshot of sources.

1 Like

That error means you are NOT using the 1.27.0 release tag, but are using whatever is on some version of master.

1 Like

I’m on 1.28.0 and I had this issue following the CNTools tutorial.
I have no idea how to fix that yet, I’m not on docker and not willing to use.

Pretty sure the CNTools tutorial says to use the 1.27.0 branch.

Check out the required branch and then follow the CNTools tutorial.