Linux users guide¶

This guide upgrades a node on Linux from any v1.12.x release to v1.13.0. Migrating to v1.13.0 explains why, and what changes for every node.

The commands use the default Ethereum Classic data directory, ~/.ethereum/classic. If you pass --datadir, use yours; for Mordor, use ~/.ethereum/mordor.

Choose how you update¶

Both methods share every other step.

Before you start¶

Record what you are running, so you can tell afterwards whether anything changed that you did not intend:

1
2
3
4

geth version
geth attach --exec 'eth.blockNumber'      ~/.ethereum/classic/geth.ipc
geth attach --exec 'net.peerCount'        ~/.ethereum/classic/geth.ipc
geth attach --exec 'admin.nodeInfo.enode' ~/.ethereum/classic/geth.ipc

Keep that last line. It is your current enode ID, and step 3 changes it.

1. Stop the node cleanly¶

• In a terminal: press Ctrl-C once and wait. A second interrupt does not kill it.
• Under systemd: stop the unit you wrote, for example sudo systemctl stop core-geth.

Wait for this line before you continue. It confirms the database is consistent:

1

INFO [..] Blockchain stopped

Stop it safely says what each kind of stop does.

2. Install v1.13.0¶

Keep the old binary until the upgrade is verified; step 6 uses it.

Method A: release archive¶

Download the archive for your processor and check it, as Installation, Linux x86_64 or Linux, ARM shows, then verify where it came from. Replace the binary:

1
2
3

sudo mv /usr/local/bin/geth /usr/local/bin/geth-v1.12
sudo install -m 0755 geth /usr/local/bin/geth
geth version

Method B: build from source¶

Building needs Go 1.26 and a C compiler. Build from the release branch, not from main, which keeps moving:

1
2
3
4
5
6

git clone --branch archive-release-v1.13.0 --single-branch https://github.com/ethereumclassic/core-geth.git
cd core-geth
make geth
./build/bin/geth version
sudo mv /usr/local/bin/geth /usr/local/bin/geth-v1.12
sudo install -m 0755 build/bin/geth /usr/local/bin/geth

Do not clone with --recursive. The submodules hold consensus test fixtures of several gigabytes, and make geth does not read them. Build from source covers the dependencies.

The executable is still named geth, so your units and scripts keep working unchanged.

3. Rotate the P2P node key¶

Required. Rotate the P2P node key explains why, and which peer lists to update. With the node stopped:

1

mv ~/.ethereum/classic/geth/nodekey ~/.ethereum/classic/geth/nodekey.old-rotated-$(date +%F)

4. Re-check RPC exposure¶

Go through the RPC exposure checklist against the flags in your unit file or start script.

5. Start and verify¶

Start the node the way you always do, for example sudo systemctl start core-geth. Then, in this order:

1
2
3
4

geth version                                                          # Core-Geth 1.13.0
geth attach --exec 'admin.nodeInfo.enode' ~/.ethereum/classic/geth.ipc   # the new ID: send it to your peers
geth attach --exec 'net.peerCount'        ~/.ethereum/classic/geth.ipc   # climbs within minutes
geth attach --exec 'eth.blockNumber'      ~/.ethereum/classic/geth.ipc   # resumes where it stopped

A peer count stuck at zero after ten minutes usually means a peer still lists your old enode ID. Last, compare eth.blockNumber with a block explorer or another node you operate. If it settles somewhere else, stop and investigate rather than resyncing.

6. If you need to roll back¶

The data directory works in both directions, so rolling back swaps the binary. Stop the node, then:

1

sudo mv /usr/local/bin/geth-v1.12 /usr/local/bin/geth

Start it again. The rotated node key stays rotated: rolling back does not un-expose the old key.

This procedure was executed before it was published¶

The claims above are measured, not inferred. The steps in this guide were run end to end against a real Mordor data directory carrying a full chain, using the published v1.12.23 binary and a v1.13.0 build:

The rollback arm is the one worth calling out. It is the step most likely to be wrong and the most damaging if it is, because it is the one an operator reaches for when something has already gone badly, and nothing had previously tested whether the older client reopens a data directory the newer one has written. It does, with the head intact.

This was run with peer discovery disabled, so any change in head across a restart would have been the client rewinding rather than the network advancing.