[Guide] Upgrading to 1.35.3 for CoinCashew Users

The information at Issuing a New Operational Certificate - CoinCashew is worth reading carefully. Prior to Vasil, as we know, the value of node.counter for an operational certificate may be any value that you choose, as long as the value is greater than the highest value that you used previously. Issuing a new operational certificate automatically increments the value of node.counter by one (1) in anticipation of issuing the next certificate. After Vasil, the node.counter value must be consistent with the current counter value for your stake pool registered on the blockchain by the protocol. If the node.counter value of your operational certificate does not correspond with the counter value that the protocol maintains, then the network will not accept blocks that your stake pool may mint because the operational certificate is invalid. If your stake pool mints at least one block using each operational certificate that you issue, then your pool is less affected by the changing functionality related to operational certificates after the Vasil hard fork. If your pool mints blocks less frequently, then after Vasil you need to get into the habit of setting the node.counter value manually when issuing a new operational certificate.

Also, Cardano Node 1.35.3 seems to require the libsecp256k1 library installed on the offline, air-gapped computer as well. There are some approaches for installing the libsecp256k1 library without connecting to the Internet in the post at Updating Offline Nodes The same information is scheduled to be included in the next release of the Coin Cashew guide as well.

CHG

2 Likes

Hi my time is set to 5 sec. Maybe that’s root cause of my issue. I will change it. thanks.

I also had to add the following line to my systemd service file (/etc/systemd/system/cardano-node.service):

[Unit]
...

[Service]
...
Environment     = LD_LIBRARY_PATH=/usr/local/lib
...

[Install]
...

Without it, I get an error that libsecp256k1.so cannot be found. I see that the CoinCashew guide solves this differently by making a link to that file in the /usr/lib/ folder (I don’t know why their file ends in .23 instead of .0 though).

2 Likes

Appreciated this - chased my tail for a couple of hours closing in but found your post & saved some time.

2 Likes

that looks fine

anyone know why I am getting

Configuring HsOpenSSL-0.11.7.2...
setup: Missing dependencies on foreign libraries:
* Missing (or bad) header file: openssl/asn1.h
* Missing (or bad) C libraries: ssl, crypto

Hey there Friends. I updated all my machines last night following the guide without issue.

STEPS OMITTED
-Install Libsodium
-Refresh Config Fils

1 Like

wget https://book.world.dev.cardano.org/environments/mainnet/alonzo-genesis.json
–2022-08-27 03:46:57-- https://book.world.dev.cardano.org/environments/mainnet/alonzo-genesis.json
Resolving book.world.dev.cardano.org (book.world.dev.cardano.org)… 3.72.231.105
Connecting to book.world.dev.cardano.org (book.world.dev.cardano.org)|3.72.231.105|:443… connected.
HTTP request sent, awaiting response… 502 Bad Gateway
2022-08-27 03:46:58 ERROR 502: Bad Gateway.

@Michael_Van_Stan
@DevJohn

I had the same problem of wget 502 errors. To resolve, I moved the configuration files back from .bak to .json, and then continued rest of steps with the original config files (I didn’t update the config files)

i also had a problem updating .gLiveView that early in the process, so did that after I completed the upgrade instead.

I have this problem. Help me please. My relay perfect, this is my core.

Ayuda @Alexd1985 También te mandé un mensaje

https://forum.cardano.org/t/re-missing-blocks-on-1-35-3-with-fresh-operational-certificate/106699?u=jccmaxon

Gracias

The site was down,

This is now working and confirmed 30 minutes ago.

I don’t understand this direction actually…
I’ve ran my systems from Jan 28 to Aug 27th without restarting any service until today when I’m upgrading, and continued to produce blocks the entire time… so not sure why this recommendation for topologyUpdater.

On the one hand, for getting your produced blocks distributed the incoming connections are more important, since they pull the blocks from you. And for incoming connections, it is only important that you ping the topology updater service every hour.

On the other hand, some of the pools that you got from the topology updater service half a year ago might still be there. So, it will somehow work even without restarting. You will still have some outgoing connections.

But if everybody did it that way, new pools would have a hard time getting incoming connections at all. They register with topology updater, topology updater will put them in their database, but if nobody restarts regularly and uses that information, nobody will connect to them.

That being said, things will hopefully move to P2P mode soon, eliminating the need for topology updater entirely.

1 Like

Thanks to these awesome guides my pool is successfully upgraded to the 1.35.3 version without problem.

1 Like

Thanks. Great guide. All nodes are running!
1 - I did not update Libsodium
2 - I had to revert to the original Configuration files so that Grafana reporting wasn’t affected.

Hey All!

Just a heads up. Missed slots have increased DRAMATICALLY from this update. A way you can resolve this is adding “SnapshotInterval”: 86400(core) & “SnapshotInterval”: 43200(relay) to your mainnet-config.json file and restarting your node.

image

Do you know what these default to if they are left unset?

I assume by “core” you mean block producer node. I don’t understand how changing something on your relay will affect missed slot checks on your block producer?

My understanding around missed slot checks centres on the processor being tied up doing memory allocation + garbage collection and hence is unavailable for the leadership check right at the precise tick required. When a snapshot occurs, this involves significant allocation of new memory and garbage collection so this causes the tying up of the processor.

Snapshots still need to happen though, so how does changing the timing interval fix the problem as opposed to just changing its timing?

Hi there,

So it is 1 hour by default I believe.And yes core is block producer. Changing the SnapShot Interval makes it happen on a less frequent cadence. And the only effect I have noticed is that the node takes about one more min to start up because the snapshot is a bit older. I have ran this fix now for a whole epoch and have noticed my missed slot percentage drop for 0.23% → 0.03%

Again this is just a quick fix suggested by a member of our xSPO group and a majority of us are running it now with no issues. If you have a better solution would love to hear it!

I found that running with RTS settings “-N --nonmoving-gc” enabled my block producer to have 0 missed slot leadership checks. However, this also means that I have to restart cardano-node every day otherwise it gradually uses more memory and eventually gets killed by the OS for causing an out of memory condition. This is because the --nonmoving-gc in Haskell 8.10.7 doesn’t release memory back to the OS. Apparently this is fixed in Haskell 9.2.x but it is not possible to compile cardano-node with this version yet.

So, I just keep restarting my node and wait hopefully for the Cardano devs to refactor the code so that it will compile with ghc 9.2.x one day.

Maybe it could be possible for the code to be refactored so the slot leadership check was done in a separate thread not dependent on waiting for the garbage collector???