I apologise for the late post, I've been overwhelmed trying to prepare @Privex for HF25, prepare my own servers, and provide one-on-one upgrade assistance to many close witness friends, and Privex customers.
This article covers how to upgrade from Hive HF24 to HF25 as quickly as possible for Privex Node-in-a-box VPS customers, as well as people who use normal Hive-in-a-box (hive-docker) on a Dedicated Server, or normal non-NIAB VPS.
Note that this post was written relatively quickly without fully testing the guide, nor checking for any typos / grammatical errors, to ensure any Hive witnesses who use HIAB and haven't yet upgraded - will have time to see this post and follow the instructions.
HF25 is due at 14:00:00 (2:00 PM) UTC (15:00 / 3:00 PM United Kingdom BST Time) - or roughly 7-8 hrs from when this post was published.
Click HERE to see the current UTC time, with realtime updates
Updating a Privex Node-in-a-box VPS
If you have a Privex Node-in-a-box (NIAB) VPS, e.g. a VHIVE8-SE or VHIVE16-FI which is still running HF24 - you need to contact support for a reinstall.
Urgent Pre-installed HF25 Server
If you need a HF25 Hive Server urgently, and your existing servers aren't possible to repair in time for the HF, you can order one of our 8GB or 16GB Hive Node-in-a-box VPS's from @Privex - which are delivered within 20 minutes of payment (as long as you leave the notes blank, and don't use a referral code unless you're 200% certain that it's a valid referral code, since if it isn't, the order will be flagged for manual inspection to attempt to identify the intended referral).
🇸🇪 SWEDEN (SE)
🇫🇮 FINLAND (FI)
Updating a normal Dedicated Server or non-Privex VPS from HF24 to HF25
If you're running Hive-in-a-box HF24 on either a Dedicated Server (whether Privex or not), or a normal VPS (one that is definitely not a Privex Node-in-a-box Pre-Installed Hive server), the upgrade to HF25 can be done within 30 mins to 1 hr, so long as your server has a high-speed network connection, has a recent block_log without any known corruption, and you're able to run the official someguy123/hive images which I release.
Before doing anything, enter the folder where you've installed hive-docker. Most people install it in their home directory.
cd ~/hive-docker
Update Method 1 - Shared Memory Transplant - Fastest, but only works with my official binary docker images
First, you'll want to make sure that the hive-docker repository is up to date, so that you have the latest features and bug fixes required for the upgrade to go smoothly:
git fetch
git checkout master
git pull
Next, you'll want to install the HF25 Docker binary image. On most setups, a standard ./run.sh install would work, but to avoid the risk of some people having configured a different default docker image in their .env, it's best to specify hf25:
./run.sh install hf25
Now, you'll need to stop your node - if it's actually running:
./run.sh stop
To help avoid corruption/contamination issues, and to potentially speed the downloads up by preventing rsync from having to calculate the differences between Privex's copy, and your copy of shared_memory.bin and block_log.index - it's best we remove them:
./run.sh clean shm
rm -fv data/witness_node_data_dir/blockchain/block_log.index
It's now time to truncate/update your block_log, replace your block_log.index, and obtain a fresh copy of shared_memory.bin for HF25:
DL_SERVER="se1.files.privex.io" ./run.sh fix-blocks
- When asked whether you want to download the rest of the block_log, or truncate your block_log, press
yand then hit enter. - If it instead says that your
block_logis the same size as the remote, and wants to do an "integrity check" or "verify the block_log, pressnand hit enter. - When aksed if you want to replace/update/synchronise your
block_log.index- pressyand hit enter. - When asked if you want to download/synchronise your snapshot files, press
nand hit enter. - When asked if you want to download/update/synchronise your
shared_memory.bin- pressyand hit enter.
Assuming everything went well, your server should now be ready to start.
Time to start your server:
./run.sh start
Now check the logs, and monitor it as it syncs.
./run.sh logs
If it takes more than 5 minutes to start outputting "Got X transactions from witness someguy123 on block 123456778" - then you should run ./run.sh monitor to see the sync progress.
Either way, it's a waiting game, it shouldn't take more than 20 mins to sync up (assuming you're following this guide within this week - this article was written on June 30th 2021), as fix-blocks would've gotten the recently synced chain files from Privex's file server.
+++ END OF METHOD 1 - Your node should now be up, or will be up very soon when it finishes syncing +++
Update Method 2 - Load a native snapshot - Slower than shared_memory.bin transplant - but this method will work with non-someguy123 built images
ONLY FOLLOW THIS METHOD IF YOU COMPILE YOUR OWN DOCKER IMAGE, OR USE A THIRD-PARTY DOCKER IMAGE
If you use a custom image - whether one you built yourself using ./run.sh build, docker build, - or one you downloaded from someone who isn't me - the shared memory transplant will likely be incompatible.
For this method, follow everything in method 1, but DO NOT follow the y/n suggestions for fix-blocks, instead, you'll want to answer them in the following way instead:
- When asked whether you want to download the rest of the block_log, or truncate your block_log, press
yand then hit enter. - If it instead says that your
block_logis the same size as the remote, and wants to do an "integrity check" or "verify the block_log, pressnand hit enter. - When aksed if you want to replace/update/synchronise your
block_log.index- pressyand hit enter. - When asked if you want to download/synchronise your snapshot files, press
yand hit enter. - When asked if you want to download/update/synchronise your
shared_memory.bin- pressnand hit enter.
ONLY FOLLOW THIS METHOD IF YOU COMPILE YOUR OWN DOCKER IMAGE, OR USE A THIRD-PARTY DOCKER IMAGE
Now, use ./run.sh clean shm to ensure you don't have a shared_memory.bin, since an existing shared_memory.bin file will cause problems.
./run.sh clean shm
You can now load the native snapshot using the command:
./run.sh loadsnap privexsnap
This will generate a shared_memory.bin using that snapshot, and once it's finished loading the snapshot, the node will automatically start normally, so for a witness node, that means it will be ready to start producing once it's finished loading the snapshot, and syncing up any blocks which it was behind.
All you have to do now, is monitor it (if you like), to track it's progress, and make sure nothing is going wrong:
./run.sh logs
+++ END OF METHOD 2 - Your node should now be up, or will be up very soon when it finishes syncing/loading the snapshot +++
Thanks for reading!
GIF Avatar by @stellabelle
Do you like what I'm doing for Hive?
Vote for me to be a Hive witness - every vote counts.
Don't forget to follow me for more like this.
Have you ever thought about being a witness yourself? Join the witness channel. We're happy to guide you! Join in shaping the STEEM economy.
Are you looking for a new server provider? My company @privex offers highly-reliable and affordable dedicated and virtual servers for HIVE, HBD, EOS, LTC, BTC, and even DOGE! Check out our website at https://www.privex.io
You can join Privex's public Discord at https://discord.privex.io - we also have a Matrix server, sign up at https://riot.privex.io (or if you have an existing Matrix account, join our General chat at #privex:privex.io)