Unable to complete Stake Pool Setup using AWS

Hi Everyone,

Please forgive me, as I am greener than green when it comes to Linux. I haven’t touched it in well over a decade and even then, it was just to play around with it. However, I do have plenty of IT experience.

I’m following these instructions:

I’m using an AWS Server (t3a.large with 80 GiB of storage).

Everything seems to work fine, but when I use the “cabal build all” command, it just sits there at the follwing:

[xxx@ip-xxx-xxx-xxx-xxx cardano-node]$ cabal build all
HEAD is now at b364d92 Merge pull request #201 from input-output-hk/upgrade-to-cabal-
HEAD is now at f730793 Merge pull request #69 from newhoggy/add-ghc-8.6.5-and-8.10.2-to-ci
HEAD is now at 09789049 Merge pull request #2107 from input-output-hk/better-min-utxo
HEAD is now at ee4e7b5 Merge #146
HEAD is now at cde90a2 Re-enable support for GHC 8.6.5
HEAD is now at 563e79f Merge pull request #610 from input-output-hk/cad-2069-fix-readsysstats
HEAD is now at 6cb9052bd Merge #2889 #2891
Warning: Requested index-state2021-01-10T00:00:00Z is newer than
hackage.haskell.org’! Falling back to older state (2021-01-09T22:55:53Z).
Resolving dependencies…

I’ve checked some other people who have the same issue, but haven’t found a solution that would work for me. But, I fully admit this could be due to my lack of experience with Linux and Cardano.

Any help would be greatly appreciated.


Upon further reading, I’m seeing that I have to sit tight and that it can “take forever” to resolve the dependencies. I’ll let it run for 24 hours and I hope that’s enough time.

You might check my thread to build your own AMI. You build on a huge instance so it goes as quickly as possible, then launch the AMI on cheaper instances. It costs less than $1 to build the AMI.

I have been able to get further in this, but now it seems to hang overnight (almost 12 hours) at the following place.

Any advice would be greatly appreciated.

Based on what little you have said, I presume you are running out of CPU credits on your instance.

You are using a T3a instance size, which relies on CPU credits in order to do work. Compiling Cardano is very resource intensive, so you are using up all of your CPU credits, which causes everything to grind to a halt. You can set your T3a instance to have unlimited CPU credits, but that actually causes it to become more expensive over time than an equivalent instance that doesn’t rely on CPU credits.

Use an instance which isn’t “burstable” in order to over-come this. This is why I created an AMI. I can use an expensive heavy-weight instance to build everything, then run it on a cheaper burstable instance.

I believe the M4 instance types are the cheapest general computing instance that don’t rely on burstable CPU credits, but they are more expensive than the T* instances.

Instance comparison tool:

Thanks Bruce - I’m looking for something that I can build and learn from, but I appreciate you offering that solution.

1 Like

Hi Bruce - thanks for that, I do have the “Credit specification” box (which says “Unlimited”) checked off, so I think that would give me unlimited CPU cycles? If not, what setting would I want? I don’t mind the extra billing, as I’m using this as a learning experience and have the budget.

The “Unlimited” setting is somewhat new still, so I don’t have a ton of experience in how it behaves. I would presume that checking the box would make your instance run as though it were an M* type, but there may still be throttling going on behind the scenes. I will say that building from sources on any T-type instance will be difficult because they are pretty slim in the resources department. You might try bumping up into a T3a.xlarge and see if that gets things moving again.

Cost wise, things start ticking up pretty quickly per day as instance size increases:
t3a.large - $1.8
t3a.xlarge - $3.6
m5a.xlarge - $4.12

Would the m5a.xlarge cover all I need and then some? And that’d cost about $4.12 a day?

Possibly. I haven’t tried to compile the sources on an instance that size, but I think it would work out fine. It will still take a few hours. It’s also sized correctly for the recommended system specs as well.

Excellent - I shall try it shortly and let you know. Really appreciate the help on this.

No problem. I’ve been working in AWS for about 5 years, so I’m pretty familiar with it at this point XD

Hi Bruce,

Thanks for all your help and I’m sorry it took so long to reply. I didn’t give up! Just had a super busy month at work and no time to focus on this as much as I should have. I moved over to the Ubuntu option in AWS and followed these instructions:

Now, it all worked and I did get the entire blockchain to download.

However, once I stopped the node to update the topology file and then restart the node, I was showing Epoch 0 again when I go into gLiveView.sh

It looks like this:


From there, I did check the status of the node and got this:

So, it looks like the node is running. When I run the “journalctl --unit=cardano-node --follow” (no quotes) command, I do get results for the current date/time and it shows progress.

I have stopped and restarted the node. I’ve rebooted the instance, as well. It just continues to report that it’s Epoch 0. But, before I updated the topology file, I did have it fully sync and get to the current Epoch.

I found this link and tried to apply it to my situation, but couldn’t execute some of the commands because I’m still too new to Ubuntu.

Any ideas would greatly be appreciated. I’m just trying to set up a small node for fun and to learn the technology.



Another update…

After working on it most of the night, I think I have both instances set up correctly (main node and relay node). However, I think it’s now a firewall issue on the nodes.

Main Node Settings:
SSH only from My IP
All Traffic only from Relay Node IP

Relay Node Settings:
SSH only from My IP
All Traffic from Anywhere

This is what my main node is doing - it won’t sync.

The Relay Node is syncing, though.

I feel like I am getting closer!

Hi what is in your topology file, does it contain your relay nodes ip’s [ public ip v4 or ipv6 ]? Also can you verify if your relay and bp are 100%? Double check your firewall inbound rules on your BP node security.

For additional troubleshooting firewalls, You can open up the BP Instance to all traffic for now to ensure your relay can ping against it. Then rebuild the inbound traffic firewall rules once you have a successful connection and operational.

I also recommend following 1 of the big guides. coincashew guide will work 99%-100% if you follow it to the instructions laid out. Guide: How to build a Cardano Stake Pool - CoinCashew

I’m running t3a.large instances without issues for now. I had a lot of issues running t3a.medium instances on relays.

t3a.medium issues: (In my case)

  • relays would take time to start
  • installation was slow
  • nodes would take time to sync
  • db would download slow
  • relays would struggle when topologyUpdater had many nodes.

t3a.large seems to work fine, but I’m not sure if there are better options taking price/performance in consideration. So far it’s working good.

the t3.medium was good up to about 1.26. You’ll need at least 8gb memory but I recommend going to 16gb if you’re planning to be a SPO til end of summer at least. With the upgrades coming, you’ll end up upgrading to another instance type. CPU usage is needed for BP if you want the least amount of downtime possible when upgrading to the latest builds. If you have a standby instance in which you can perform the upgrade and it is associated by static ips, then you can get away with min down time.

1 Like

Hey everyone,

So I think I got past that issue and now am going to have to do the air gapped machine for the keys. I have the BP fully synced and the Relay Node working and also fully synced.

I’m on Step 9 of the Coin Cashew part, so I’ll continue that part over the weekend.

PS - I had tons of issues using t3a.xlarge (it would hang, I’d run out of credits, etc). So, I am using m5a.xlarge for both and they are running beautifully. They still took about 12-14 hours to download the block chain. Cost wise, I can see they may not be the most efficient, but once I get them going I don’t want to have to stress over upgrades, etc.

Thanks again about the community help and I’ll be posting my full experience and how I went from 0 experience in this area (but over 20 years in IT) to getting a node operational (with a lot of help that has been appreciated and will continue to be appreciated).


Chris Schuh

1 Like

Great to hear! welcome to the community.

Thanks a lot for the welcome and the help.

So, I’m just having issues now with checking if my pool is in the blockchain.

I get this error:

REDACTED:~/cardano-my-node$ cardano-cli query stake-snapshot --stake-pool-id $(cat stakepoolid.txt) --mainnet
Invalid argument `stake-snapshot’

Usage: cardano-cli query (protocol-parameters | tip | stake-distribution |
stake-address-info | utxo | ledger-state |
Node query commands. Will query the local node whose Unix domain socket is
obtained from the CARDANO_NODE_SOCKET_PATH enviromnent variable.

I did miss putting in some of my pool data in the registration certificate, so I went back and corrected it and then went through all the steps again, but then I got a negative value error in the transaction build command.

I think I am almost there (if not already there)!

Any help would be truly appreciated.


Chris Schuh