You are advised to downgrade from 2.2.0 to 2.1.4

General Chia Discussion
1

From Discord:

Hey all, we found an unfinished block selection issue with 2.2.0 which can create corrupted blocks in the impacted user’s local database. We recommend users revert to 2.1.4.

The Issue:
2.2.0 may potentially cause your node to ban peers erroneously or to be banned by them in turn.

Next Steps:
Work is underway to provide a tool for validating synced blocks in your local database and an up-to-date Chia DB checkpoint (validated with the tool) for download - you should download this snapshot DB if your node becomes unable to sync or acquire peers. We’ll notify you when both are available to use.

Download 2.1.4 Here:

Our team is available in the support channel.

Install Notes:
For Mac and Linux Users, you should be able to simply install 2.1.4. For PC users, we recommend uninstalling 2.2.0 and installing 2.1.4 – Please take care to preserve your configuration files.

We’re also working to get 2.2.1 put together and out to you soon™

7 Likes
2

Now having problems with 2.1.4 - seems to be looking for Flexpool, and hanging the full node part when it can’t find a DNS entry for it.
I went though the configuration, it’s NOT in there - seems to be something hard coded.
Only been an issue the last 3-4 days since the DNS entry for flexpool expired.

3

Perhaps it would be an idea to download 2.2.1

Won’t be long and 2.3 will be out, its currently on rc2

4

I can’t wait to see the Quality Control they execute for the hard fork.

1 Like
5

Hopefully 2.3 will fix the issue, as 2.21 has had ZERO effect on the hang or what I’m seeing in the error logs.
There isn’t ANYTHING in the config that I can find about flexpool, it’s acting like something flaking out and not letting it start because the DNS record for flexpool probably expired in the last week or so.

6

Maybe it only needs to check whether the name is resolving or http server is behind that DNS name, not get some data from it. In such a case, maybe you could create flexpool.io in entry in your hosts file pointing either to your local box, or some http server you control. If such check would be successful, you could add flexpool pool back to your config.yaml and right after switch from it to solo (removing any references to it). I would assume that chia would force switch to solo, to stop eventual hostile pools from preventing such switch.

7

You’re missing part of the point.
I don’t HAVE any “flexpool” entry of any sort in my config.yaml in the first place, yet I’m getting this error AND the full node is hanging up apparently due to it.
Why would I add it back when the pool hasn’t existed for several months?

The hosts entry as such though is something I will try as a work-around to the entire problem, though pointing it at a HTTP server I control won’t work since I don’t run such a server.

8

So if Flexpool is gone remove anything connected to it, edit the config.yaml and remove all enties that say anything about flexpool. Once you made a backup first!!!

9

Maybe I didn’t write it clear enough; however, you are still missing the point or rather have no understanding what the wallet does yet start rambling.

The fact that you don’t have any flexpool entry in config.yaml has no bearing on what wallet knows / does. As long as you have used at any point flexpool and not switched that plot NFT to solo (or other pool), the wallet will try to check on it every so often without respect of what you have in config.yaml.

Removing “old” pools from config.yaml is just aesthetics for chia GUI part (they didn’t bother to implement ‘archive’ function, what was asked a couple of years ago). All is good, as long as those pools are still working and/or DNS is live, as the wallet is happy making dumb checks. Once the DNS goes south, the wallet code barfs most likely on DNS lookup. Therefore, providing a dumb http server that will somehow respond will quiet down the wallet (you can check pool docs what eventual ‘get-lost’ response is, and feed it back if needed). However, to fix the problem (bug in chia code), you will need to add that flexpool back to config.yaml and switch that NFT pool to solo. This way, the wallet will not be checking it anymore / barfing when DNS is missing.

10

Unfortunately, that’s not enough. You need to also unsubscribe from such pool.

11

But if the pool is dead and not running, then what to do???

12

If you don’t have that pool entry in the config.yaml, stop chia / move config.yaml / (maybe delete the wallet db, not sure) / start chia / it will generate new config with that pool / stop chia / copy that pool entry to the old config.yaml / edit host file to resolve that pool DNS name / start chia / try to switch that pool to solo.

Hopefully the code is barfing on trying to resolve that DNS name, so that hosts entry may do the trick (it is normal that servers are down, so the code may tolerate this better). However, if that will not do the trick, there will be a need to put some simple http server that will respond to that query, maybe just saying OK. If that is not enough, pool docs should have the info how to provide a “get-lost” response.

Basically, the wallet deals with blockchain, not really with config.yaml. If the blockchain says that such missing pool should be active, the wallet will try to query it, regardless of what is in config.yaml.

13

I’m not mining on that wallet/full node AT ALL.
I did use Flexpool at one point - haven’t been any plot NFTs with Flexpool it can see (OR that exist) for many months now, perhaps a year?
And it’s not THE WALLET that’s having the issue - it’s the FULL NODE not starting up, which of course stops the wallet from working.
I do appear to have not specified that in my early posts.

14

I cannot say what is the exact sequence of events between the daemon, the node and the wallet to exactly point to the offending file / line. Also, rather have no interest in investigating it.

The daemon is only interested in starting needed services (e.g., the node and the wallet), not in knowing what the status of a given plot NFT / subscribed pool is.

The same could be said about the node. Its interest is in interacting with the blockchain and maintain a full local copy of bc (that will be available for the wallet to do its job).

On the other hand, when the wallet is started and it is creating its local wallet db from scratch, it will parse the whole local bc (if available (as it is considered locally trusted), if not it will connect to the external nodes), and get all the info related to itself, it means scan for any plot NFTs that were created at any point. This is where the wallet knows that you have one with an active subscription to flexpool. Regardless of what is specified in the config.yaml, the wallet will interrogate all pools that have an active subscription to its NFTs. This is where it will try to resolve the DNS name of flexpool, and if successful, will query it (e.g., to get the current difficulty). Assuming that the DNS is there, but the pool responds with a garbage (i.e., no pool running), it will kind of gracefully barf (producing an error indicating the offending pool - what you should see in your old logs before flexpool’s DNS expired). However, when the DNS is not there, it is most likely barfing seriously bringing down itself (the wallet).

As the daemon is waiting for all services to finish the startup process, it will never get response from the wallet, thus will hold the whole startup process.

Again, I didn’t go through the code, but assume that this is the simples / shortest description of the full startup, and where the wallet / flexpool is coming into the place and why the whole startup is broken in your case (or others with the same problem).

And WHERE your STARTUP LOGIC is coming from? What makes you think that “of course” the node (or rather the daemon) is holding the wallet from starting? Could you describe the process you have in mind?

15

How does the Wallet get information without the full node to access?

And as I ALREADY SAID, it’s the FULL NODE that’s not starting.
As the GUI does not start fully 'til all the daemons are started up - THUS THE OF COURSE part of my comment.

16

Really? You didn’t bother to read what I wrote? You do understand what db is, do you?

YOU ARE STILL CONFUSED AS YOU HAVE ZERO UNDERSTANDING OF HOW IT WORKS.

17

You’d rather be rude and insulting instead of just answering the question.
Your reply certainly does NOTHING to reduce any confusion on my part.

Also, the startup code DOES indicate that the WALLET starts - which destroys YOUR claim to know what is going on, and YOUR ASSUMPTION about the startup logic, thus rendering your wall of text about YOUR ASSUMPTION wrong.
So no, I didn’t waste my time reading most of what you wrote since you made it quite clear that you were AT LEAST AS CONFUSED and had no understanding of the actual process.

18

I have described the startup process, and how your observations fit to it. However, you didn’t bother to read it, and keep rambling.

I have also described how to fix the problem. However, you didn’t bother to read it, not to mention try it.

I have no problem answering your questions where my explanation was not clear enough for you. But there is no point to restate the same thing over and over, as you know better and are going full COBOL to show it.

However, this is you who is just tossing memorized keywords around that don’t fit the context, and stating what is wrong with your farm without providing any evidence how you arrived at that other than “I said so”.

Maybe you could look at the mirror, or read how you keep replying and not just in this thread.

As they are saying “you can take a horse to the stream, but you cannot make it drink”. You have all the info there, it is up to you to drink, or keep rambling.

As you can see, contrary to what you stated, I wrote that wallet will start; however, it will shut-down due to DNS problem (with flexpool in your case) holding the whole process.

This is one of your replies that show how full of shit your answers are and why it shows that you have no idea what you are talking about and are here just for the rambling part.

1 Like
19

When your reply did not fit what I see when I start up, why would I bother reading it?
You also stated that you were ASSUMING how it worked, not speaking from experience or knowledge of the code.
And what the heck is “going full COBOL” supposed to mean?

“As the daemon is waiting for all services to finish the startup process, it will never get response from the wallet, thus will hold the whole startup process.”
This indicating that the Wallet never starts up and is somehow stopping the NODE from starting up.
No, you specifically DID NOT say “I wrote that wallet will start”, and in actual fact it does NOT “shut down” nor give any indication of such.

“This is one of your replies that show how full of shit your answers are”
how applicable to YOUR replies.

20

I don’t know how else to interpret the bolded text other than the daemon is starting all services (including the wallet) and waits for them to report back that they started successfully (including the wallet) before proceeding / letting know the GUI that all is fine. The wallet is one of the key parts of the running farm, so if it cannot start for some reason (crashes / gets stuck), there is no point to have the GUI working.

Also, how convenient it is to just partially quote what I wrote. You forgot about the first part:

Doesn’t it imply to you that the wallet needs to somehow start to interrogate those pools? If not the daemon, what process will start it, some kind of magic, or wishful thinking?

One of the main functions of chia daemon is to start all services (meaning, node / farmer / harvester and of course the wallet) and wait till all of those report success. Only then the GUI is working. Therefore, as every other service the wallet is started. The first thing that wallet does is asking all pools about the status. As it cannot resolve flexpool it exits / gets stuck and never notifies the daemon that it has successfully started. This is why the daemon is stuck and the GUI never fully starts.