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 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-3.4.0.0-rc5-on-windows
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.
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.
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.
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
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.
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.
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.
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.
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.
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).
Usage: cardano-cli query (protocol-parameters | tip | stake-distribution |
stake-address-info | utxo | ledger-state |
protocol-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.
