Withdrawn
These node upgrade instructions have been withdrawn
This page used to carry an "ultra safe upgrade" procedure for moving a legacy node to a current one. It has been removed because one of its central claims is wrong in a way that can leave you unable to go back.
The rollback it promised is not possible. The page said
that if the new node failed you could stop the new container, start the
legacy one, and be back where you started. You cannot. Starting the new
node migrates the ledger store in place, and that migration only runs one
way. The legacy node then refuses the migrated ledger with
The version of the ledger (24) is too high for this node. By
the time you find out, the old node will not start.
What else was out of date
It recommended raiblocksone/raione:R1_V.02.2. The current node
image is caltru1sm/xro-node:2.0.3, which is multi-architecture
and runs on ARM boards as well as x86.
The whole procedure existed to preserve an old ledger, because syncing from scratch was believed to be unreliable. It is not. A fresh node syncs from genesis in roughly 45 minutes, unattended, with nothing to download first. Preserving the old ledger buys nothing and is exactly what created the one-way migration risk.
If you followed them and your node will not start
Back up the whole data directory before deleting anything.
It contains wallet.ldb as well as the ledger. If you run a
representative, that file holds your voting key, and unlike the ledger it
cannot be recovered from the network. The ledger is public data and can
always be rebuilt. A wallet key cannot.
If you made the backup copy the old Step 2 described
Restore it over the data directory and start the legacy container again. That copy predates the migration, so the legacy node will read it. Then upgrade properly using the current instructions.
If you did not
The legacy node cannot be recovered, but you do not need it. Move the data directory aside rather than deleting it, start the current node image, and let it sync from genesis. It takes about 45 minutes. Your node identity regenerates on its own and nothing about your position on the network depends on it.
If you were running a representative
Recover wallet.ldb from the directory you moved aside and load
the key into the new node's wallet. Voting weight follows the key, not the
machine, so it returns as soon as the node is synced and voting again.