I only upgraded to 1.35.3 because I was already in this mess, and didn’t want to redo it all over again after a few epochs.
I had the problem when I was using 1.33.0, and I think it was an invalid certificate most likely, but it was working, and that was weird!
If u will install cncli u will can see which blocks u lost… and u can search inside the logs (by block number) what was the reasson
Or try this way
Since version 1.34, it is possible to check the slot leadership schedule for the current and next epoch using cardano-cli.
Next epoch’s leadership schedule becomes available 1.5 days (36 hours) before the end of the current epoch.
Next epoch’s leadership schedule is obtained with the following:
cardano-cli query leadership-schedule \
--mainnet \
--genesis $NODE_HOME/mainnet-shelley-genesis.json \
--stake-pool-id $(cat $NODE_HOME/stakepoolid.txt) \
--vrf-signing-key-file $NODE_HOME/vrf.skey \
--next
Current epoch’s leadership schedule is obtained with the following:
cardano-cli query leadership-schedule \
--mainnet \
--genesis $NODE_HOME/mainnet-shelley-genesis.json \
--stake-pool-id $(cat $NODE_HOME/stakepoolid.txt) \
--vrf-signing-key-file $NODE_HOME/vrf.skey \
--current
PS: u may need to adapth the path for the files
Yep. And managing with one method is pretty incompatible with the other one if you don’t know exactly what you are doing there. 
Okay, so here is my update. I successfully upgraded to 1.35.3 and my BB is running on a new certificate and KES keys. My two relays are up and running and the result of pool.vet says that everything is great. I assume now that I just need for my BB to start minting, I hope. I am going to install leader log to check things.
Update: When I downloaded the needed files for Leader Log and the scripts themselves, I tried to run your code @Alexd1985 cardano-cli query leadership-schedule but it didn’t work. I also tried to run
cardano-cli query leadership-schedule --mainnet --genesis /$NODE_HOME/mainnet-shelley-genesis.json --stake-pool-id “7102ce043d15b9f9ff47b118142b978339c6dda4f204d403331e1fff” --vrf-signing-key-file /$NODE_HOME/vrf.skey --current
But it didn’t work either and said something about network socket. I have that already defined in the .bashrc, so I checked my BB journalctl, and now it’s validating chunk again, which is weird. It used to be all fine and great, but things went south after installing leader logs. Is this suppose to happen?!
How much ram has the BP? If u don’t have enough (~24G) it will kill the node
The BP and the two relays are 16 GB each. So you mean that your command killed it because it does not have sufficient memory? If it’s a memory issue only, I can add more, but I want to make sure that everything is good and as it should before I do that
Exactly, it is an insufficient MEM issue; if u have the posibility add more for BP
If u check with journalctl -e -f -u cardano-network u should see kill/killed messages
It’s empty!
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal' can see all messages.
Pass -q to turn off this notice.
-- Logs begin at Fri 2022-08-05 21:59:23 IDT. --
sorry, long night
journalctl -e -f -u cardano-node
Does this all look normal to you? Is my BP functional and minting?
If the op.cert is valid should be fine… all looks ok inside glive
Here is what the cardano-cli query kes-period-info looks like. I assume that when I start minting the qKesNodeStateOperationalCertificateNumber will turn automatically to 5, right?
✓ Operational certificate's KES period is within the correct KES period interval
✓ The operational certificate counter agrees with the node protocol state counter
{
"qKesCurrentKesPeriod": 533,
"qKesEndKesInterval": 595,
"qKesKesKeyExpiry": null,
"qKesMaxKESEvolutions": 62,
"qKesNodeStateOperationalCertificateNumber": 4,
"qKesOnDiskOperationalCertificateNumber": 5,
"qKesRemainingSlotsInKesPeriod": 7958710,
"qKesSlotsPerKesPeriod": 129600,
"qKesStartKesInterval": 533
}
all good
I enjoyed reading this thread even though i’m not running a pool. I thought about it when i first arrived on the Cardano scene, but then thought i should first stake to a well read pool for about 1.5 yrs now.
I’m glad i took the route, as i’ve learned a lot… and not at others expense… as i can’t guarantee 24/7/365 uptime for blocks etc…
your thread has edu’'d me even more. thanks for posting online where interested parties can learn about the entire ecosystem.
I just want to report back that everything is perfect while running 1.35.3
My BP is minting blocks, and my qKesNodeStateOperationalCertificateNumber turned to 5.
Thank you everyone!
Hey Alexd where does adapool show our KES counter?
If you are referring to the operational certificate number, it will be under “Blocks” then look at OpCertC.
If you are referring to the remaining period of the KES keys, then you can find that info easily when you access the gLiveView.sh