Closed sensay-nelson closed 6 years ago
pete001
commented
6 years ago Interesting! I tried this on a fresh node, even updating the eos version, and i get the same.
Must be a legit issue with a submodule reference on their side.
I will keep this issue open until the EOS devs have fixed this.
sensay-nelson
commented
6 years ago Thank you for the confirmation @pete001 . For the time being, setting recursive: no seemed to work ok and the build finalized, although I can't say I know the actual implication of doing this, but it does seem to work. I was able to get the node started and it looks like it's up to date.
#changed recursive to "no" in eos-mainnet/deploy/tasks/main.yaml
- name: clone repo eos
git:
repo: "{{ repo }}"
recursive: no
dest: /opt/eos
update: yes
version: "{{ version }}"
track_submodules: yes
force: yesThis may be the wrong forum and I can remove this comment if so...
If I can give some feedback on the online documentation (since I see you are a contributor and I can't make pull requests against the website)...
Looking at the instructions at https://eosnode.tools/blocks, the --config-dir /opt/mainnet option is missing.
Without it, it was basically using the default configuration which does not have adequate memory allocation and so was failing. It took me several hours of googling before I realized what my mistake was.
# Start up nodeos pointing to the data directory, request a hard replay of the chain using wavm to speed things up
nodeos --data-dir=/opt/mainnet --hard-replay --wasm-runtime wavm
# I think should be:
nodeos --data-dir=/opt/mainnet --config-dir=/opt/mainnet --hard-replay --wasm-runtime wavm Overall the instructions/process/automation at https://eosnode.tools are by far the absolute best I have seen / used anywhere and am extremely grateful for all your hard work. I do probably have 4-5 pieces of other feedback I think folks would find useful for getting started, but I feel I've hijacked this thread enough. If you/BlockMatrix is interested, please let me know the best place to communicate them. Again, thank you and BlockMatrix for everything.
pete001
commented
6 years ago Oh this is awesome feedback, thanks @sensay-nelson!!
I will update that documentation on eosnode.tools, and would love to hear the other pieces of feedback, will keep this thread open for that.
sensay-nelson
commented
6 years ago A few things I bumped my head on while getting started.
If I were running an API Node into AWS, I would suggest an
Currently in the startup script and config.ini, these are the same folder, which isn't necessarily going to be true, especially if you are in AWS/Google and using ebs volumes (which are handy if I wanted to re-attach my blocks to a different instance size later, for instance). I may make a pull request for this allowing it to be a config option in ansible and updated in both files via template.
On https://eosnode.tools/automation, the below instructions were confusing for a couple reasons. 1) it's not using your own block backups by default, which is definitely going to be a far faster solution. 2) using genesis.json file contradicts the many p2p-peer-address ansible configured in config.ini. If I understand correctly, Genesis.json is specific to each block producer and only the block producer for which the genesis.json file you are using should be configured in the p2p-peer-address if you are going to start from scratch. If you try to start it with all the p2p addresses, they disconnect telling you "wrong chain". So, out of the box with running ansible and this command did not work.
# Launch the chain for the first time
ssh user@nodeip
cd /opt/mainnet
./start.sh --genesis-json /opt/mainnet/genesis.jsonI would replace it with something like
# Install the mainnet config
ansible-playbook mainnet.yml
## Finish
Download the latest block backup and start nodeos at
https://eosnode.tools/blocks...And on https://eosnode.tools/blocks, I would use the start script with the extra options so no one accidentally starts it non-daemonized, as it will start all over again if you cancel the process.
# Move to your nodeos data directory (remove existing blocks and state dir if relevant)
cd /opt/mainnet
rm /opt/mainnet/blocks
rm /opt/mainnet/state
# Download the latest blocks backup for Ubuntu 18.04
wget $(wget --quiet "https://eosnode.tools/api/blocks?os=Ubuntu+18.04&limit=1" -O- | jq -r '.data[0].s3') -O blocks_backup.tar.gz
# OR Download the latest blocks backup for Ubuntu 16.04
wget $(wget --quiet "https://eosnode.tools/api/blocks?os=Ubuntu+16.04&limit=1" -O- | jq -r '.data[0].s3') -O blocks_backup.tar.gz
# Uncompress to ./blocks
tar xvzf blocks_backup.tar.gz
# Start up nodeos pointing to the data directory, request a hard replay of the chain using wavm to speed things up
./start.sh --hard-replay --wasm-runtime wavm
# Tail the logs
tail -f /opt/mainnet/log.txt
Nodeos should copy the blocks to a backup directory, and then begin the replay. This will likely take 2-3 hours, depending on CPU. Once replay is complete up to the current backup block, the chain will begin to synhcronize with the other p2p nodes configured. This will also take 2-3 hours, depending on how far ahead the mainnet is.
<< copy of expected log output >>That's it. Mostly just minor stuff, but piece by piece it took up a bunch of time and learning. Again, terrific work and thanks for your help. Now that I am going it is fun :)
Edit: updated the recommended system requirements and AWS ec2 specs. 8gb is enough to compile, but not enough to hold the blockchain in memory. I now recommend at least 16gb, 32gb ideally. I have successfully been running for 3 days on an m5.2xlarge.
pete001
commented
6 years ago This is epic!!
Thanks so much for taking the time to do this. I will incorporate of all this feedback and push up tomorrow.
pete001
commented
6 years ago Thats all incorporated now, thanks again @sensay-nelson !
I am seeing the following error when running ansible-playbook eos.yml
any suggestions?