Fatal failed to register the ethereum service failed to retrieve genesis from ancient eof

Fatal: failed to write genesis block: genesis has no chain configuration #7201

Comments

dbe commented Mar 26, 2017

System information

Geth version: 1.6.0-unstable-1018bf6a
OS & Version: OSX 10.11.2

It looks like the ‘config’ attribute of the Genesis struct is required when setting up a new blockchain using the «geth init» command. As of now, no tutorials, including the official ones suggest you pass in a config attribute in your genesis.json file.

Expected behaviour

geth init works properly

Actual behaviour

geth init throws error: «Fatal: failed to write genesis block: genesis has no chain configuration»

Steps to reproduce the behaviour

call «geth init genesis.json» where your genesis.json file does not include a «config» attribute.

Backtrace

The text was updated successfully, but these errors were encountered:

fjl commented Mar 27, 2017 •

Config being required was a design decision that I made when improving the genesis loader. If the block doesn’t define configuration, what should the fork switch-over blocks be? We could set them all to zero, but that would create problems if you created your private chain with one version of geth and then ran geth init with a later version that supports a new hard fork.

fjl commented Mar 27, 2017

I will improve documentation for now, and we’ll decide about this issue before 1.6.0 is released.

karalabe commented Mar 27, 2017

I think saying «config is needed from now on» is an acceptable route if we make a clear documentation how it works. And perhaps add a link to the error message where users can read more.

fjl commented Mar 27, 2017

karalabe commented Mar 27, 2017

We have a section in our readme. I really think we should put these stuff in there. The wiki pages are a mess currently.

mavstronaut commented Mar 28, 2017

I found the only config that was actually needed was setting a path to the genesis block file. Thanks for updating the docs, I don’t remember which tutorial guided me through the first time any more

beatrizsanchez commented Mar 30, 2017

I don’t know if this is related to the random handshakes that are happening in a private network as described by John here. I am having the same issue using a unique networkId, a custom genesis file (with the configuration update you mention in Private Network documentation), yet this does not seem to avoid the random handhsakes that are diplayed when when I run admin.peers several times secuentially:

Would the use of unique «config» parameters in the genesis file help making the network private?

fjl commented Apr 6, 2017

@beatrizsanchez this is unrelated. admin.peers sometimes contains peers which are in the negotiation phase. They will be disconnected if the genesis does not match.

karalabe commented Apr 13, 2017

I guess this is fixed?

vongohren commented Apr 17, 2017

You should really update the readme aswell: https://github.com/ethereum/go-ethereum
That is currently not working

clawoflight commented May 4, 2017

@fjl Could you elaborate on this?

If the block doesn’t define configuration, what should the fork switch-over blocks be? We could set them all to zero, but that would create problems if you created your private chain with one version of geth and then ran geth init with a later version that supports a new hard fork.

What should I use when creating a private chain?

karalabe commented May 4, 2017

It’s fine if you set all your fork blocks to zero for a new private network.

@fjl was saying that we ourselves cannot default to zero automatically, because if you have a private network that’s running for 3 weeks, and then we release a new fork (e.g. Metropolis) with a default block number of 0, it will invalidate your 3 week old chain. So you need to manually add the metro fork block to your genesis at whatever you feel best and run your nodes with the new configs from that point onward.

clawoflight commented May 4, 2017

@karalabe Thanks, but I still don’t understand.

• How would I see that something stops working?
• How do I add a fork block to my genesis block?
• What would I do afterwards? Do I need to re-init the chain?

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

how to initialize a account in genesis.json file and fund it some money before mining?thank you. #14831

Comments

jiebanghan commented Jul 19, 2017

in ethereum page of github,we can see something about genesis file below:
Defining the private genesis state

First, you’ll need to create the genesis state of your networks, which all nodes need to be aware of and agree upon. This consists of a small JSON file (e.g. call it genesis.json):

<
«config»: <
«chainId»: 0,
«homesteadBlock»: 0,
«eip155Block»: 0,
«eip158Block»: 0
>,
«alloc» : <>,
«coinbase» : «0x0000000000000000000000000000000000000000»,
«difficulty» : «0x20000»,
«extraData» : «»,
«gasLimit» : «0x2fefd8»,
«nonce» : «0x0000000000000042»,
«mixhash» : «0x0000000000000000000000000000000000000000000000000000000000000000»,
«parentHash» : «0x0000000000000000000000000000000000000000000000000000000000000000»,
«timestamp» : «0x00»
>
The above fields should be fine for most purposes, although we’d recommend changing the nonce to some random value so you prevent unknown remote nodes from being able to connect to you. If you’d like to pre-fund some accounts for easier testing, you can populate the alloc field with account configs:

«alloc»: <
«0x0000000000000000000000000000000000000001»: <"balance": "111111111">,
«0x0000000000000000000000000000000000000002»: <"balance": "222222222">
>

I define «alloc»: <
«0x0000000000000000000000000000000000000001»: <"balance": "111111111">
> in my genesis.json file, then I run command below:

./geth —datadir ethereum init genesis.json

but in geth console, after I run eth.accounts, it returns null

how to initialize a account in genesis.json file and fund it some money before mining?thank you.

The text was updated successfully, but these errors were encountered:

Источник

Fatal: Failed to register the Ethereum service: gap (#492149) in the chain between ancients and leveldb #22374

Comments

osizadmin commented Feb 24, 2021

Geth version: 1.9.25-e7872729

Error : Fatal: Failed to register the Ethereum service: gap (#492149) in the chain between ancients and leveldb

We have faced the above error while start the geth in fast syncmode.

The text was updated successfully, but these errors were encountered:

TheEdgeOfRage commented Mar 1, 2021 •

I am seeing the same error after a SIGSEGV crash on the previous run. The only difference is that I’m doing a full sync.

Here is the log of the crash:

And here is the log I get whenever I try to run geth now:

I run geth using the following command:

geth —syncmode full —cache 4096

My .ethereum directory is currently 15GB, but I could upload the whole thing somewhere if that makes it easier for you guys to debug this.

ligi commented Mar 4, 2021

@osizadmin can you provide some logs? Did you have a crash before the problem you describe?

ligi commented Mar 4, 2021

@TheEdgeOfRage the crash should be fixed in the recent release — but you will need to resync. Thanks for your log this was most helpful

voronindev commented Mar 29, 2021

Hello there! We have something close to yours:

Command:
command: —gpo.blocks 10 —gpo.percentile 90 —ropsten —cache 2000 —syncmode «full» —nousb —http.api debug,eth,web3,personal,net —http —http.addr «0.0.0.0» —http.vhosts=»*» —ws —ws.addr «0.0.0.0» —ws.origins=»*» —port 30303 —ws.port 8546 —http.port 8545

no-response bot commented Apr 3, 2021

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don’t have enough information to take action. Please reach out if you have more relevant information or answers to our questions so that we can investigate further.

Источник

Fatal: Error starting protocol stack: genesis mismatch #21315

Comments

sssubik commented Jul 9, 2020 •

System information

Geth version: Geth/v1.9.13-stable
OS & Version: ubuntu 18.04

Expected behaviour

My server turned off abruptly where my full node GETH was running. Now when I fix the server and open the node the node should start running.

Actual behaviour

The GETH node before the server crashed was running fully synced and was displaying importing chain segment.
When I fixed the server after server turned off abruptly, and executing geth I am getting log as:

The server was off for around 8 hours is this the reason there is a mismatch problem? I dont know why the Genesis mismatch problem is there. Could you provide me with a solution to initialize the GETH node with a genesis block again or any other solution
Steps to reproduce the behaviour
Install GETH full node and if the server turns off due to some problem the above error shows up if you reboot the server.

The text was updated successfully, but these errors were encountered:

sssubik commented Jul 9, 2020

Hey @karalabe . Really need your help. Please could you tell me some solution or any help..

rjl493456442 commented Jul 13, 2020

Hi @sssubik sorry for the late reply. Is the corrupted database still available?

I added a debug log to expose the root error for the failure, hopefully it’s not late

sssubik commented Jul 13, 2020 •

Hey @rjl493456442 Yes the corrupted database is still available. What should I do? Do I need to resync?
Okay I will show you the log once the commit is done.. Will it be done today?

sssubik commented Jul 14, 2020 •

Hey @rjl493456442 I tried the new version and now I am getting this:

What would I need to do? @rjl493456442

sssubik commented Jul 15, 2020

Hey @rjl493456442. I did some research and found no solution. I find that the GETH once shutdown abruptly prunes the states in freezer without pruning level db due to some roll back to correct state. Could you provide me more detailed explanation or solution?

rjl493456442 commented Jul 15, 2020 •

@sssubik Can you list your ancient directory?

Something I don’t understand is items=10329515 size=0.00B there are 10M items in the ancient directory but the head file size is 0.

Now I have no clue why the ancient will return an empty genesis for you. It’s not easy to debug without a corrupted database. Maybe you can help a bit by offering some information.

sssubik commented Jul 15, 2020 •

Hey I have listed my ancient directory. Also the space I calculate gives me this:
131G ancient
If anything more need I will provide. Would be really frustrating if have to resync..

rjl493456442 commented Jul 15, 2020

Can you also give me the size of hashes.ridx and hashes.0000.rdat ? Thanks!

sssubik commented Jul 15, 2020

60M hashes.ridx
0 hashes.0000.rdat

hashes.0000.rdat shows 0 MB

rjl493456442 commented Jul 15, 2020

@sssubik I have to say sorry. I think there is a bug in the codebase, but the ancient database is already broken(and useless unless we do some manual recovery).

sssubik commented Jul 15, 2020

@rjl493456442 What does this mean. Do I need to resync? Or can I do some manual recovery? Also if I need to resync am I gonna be able to leverage the downloaded states I already have to complete resync in less time?

rjl493456442 commented Jul 15, 2020

Do you have any other synced Geth instance?

Manual recovery means:

• Drop another synced hashes.0000.rdat file there for replacement(Note, the new file should contain more elements then the broken one
• Write a script the iterate the Header table and then inject the header hash into the broken hashes.0000.rdat file. It needs some coding work, maybe not a good idea

Also if I need to resync am I gonna be able to leverage the downloaded states I already have to complete resync in less time

To be honest I don’t think we can plugin the downloaded states without any modification. The hacky way is: iterating the leveldb, delete all chain data(headers, tds, receipts, bodies, chain marker) but keep the states and then re-sync.

Download the chain is fast, download the state is painful.

rjl493456442 commented Jul 15, 2020 •

Can you search the history log that whether Truncating dangling head . or Truncating dangling indexes . or Truncating freezer table even appear?
I am digging the root cause and the log might help.

sssubik commented Jul 15, 2020 •

Hey I dont have any other synced GETH instance

Drop another synced hashes.0000.rdat file there for replacement(Note, the new file should contain more elements then the broken one

So, can I find a synced hashes.0000.rdat file from somewhere else.
Also

The hacky way is: iterating the leveldb, delete all chain data(headers, tds, receipts, bodies, chain marker) but keep the states and then re-sync.

Do you mean this geth removedb ? But isnt the problem in the ancient folder? And to resync I just run the geth command again? Also how long could it take?

Can you search the history log that whether Truncating dangling head . or Truncating dangling indexes . or Truncating freezer table even appear?

As far as I know how to search log I get this:

I cant find the log you just sent me

sssubik commented Jul 15, 2020 •

Sorry the above search of logs was wrong. I do get this:

rjl493456442 commented Jul 15, 2020

@sssubik geth removedb will also delete the downloaded state, don’t do it.

I think we can offer you the synced ancient file if you want. @holiman says «We can do that, but I don’t have time to do it during the day, maybe toward the evening»

sssubik commented Jul 15, 2020 •

@rjl493456442
Yes that would be great.. Okay I can wait towards the evening. Do I just copy the file to the ancient folder?

rjl493456442 commented Jul 15, 2020

@sssubik Yes, basically the truncated files for replacement. Do you have any other logs before these Truncating dangling head ?

sssubik commented Jul 15, 2020 •

Also The server crashed and was closed for around 10hours before reboot.

rjl493456442 commented Jul 15, 2020

Any other logs before crash?

sssubik commented Jul 15, 2020 •

Not much really. Only Imported new chain segment.

But Some other logs that were like 10hours or more before the crash:

Also this unique one:
`Jul 08 15:30:37 [418]: INFO [07-08|15:30:37.013] Chain reorg detected number=10419158 hash=ddd8ba…a8ad68 drop=1 dropfrom=0b9a3b…91797d add=2 addfrom=5f5fd6…28d552

Jul 08 16:02:25 [418]: INFO [07-08|16:02:25.609] Chain reorg detected =10419296 hash=90c89b…feb214 drop=1 dropfrom=28571c…aca82f add=2 addfrom=5c6482…cd2d7b`

sssubik commented Jul 15, 2020

Hey @rjl493456442 Can you tell your local time? Or after how much time @holiman will be available to send the synced ancient file?

rjl493456442 commented Jul 15, 2020

@sssubik No idea, probably a few hours later. Btw I would suggest you to replace all *.idx files (e.g. diffs.ridx , bodies.cidx , etc) and all *.dat files with largest file suffix (e.g. hashes.0000.rdat , diffs.0000.rdat , bodies.0048.cdat , receipts.0021.cdat , headers.0002.cdat )

sssubik commented Jul 15, 2020 •

Hey @rjl493456442
cp -f [oringinal file] [new file]
Copies the original file and overwrites the target file

cp -f diffs.0000.rdat diffs.ridx

Do you mean this?

rjl493456442 commented Jul 15, 2020 •

@sssubik No, I think @holiman will publish our ancient folder somewhere, you only need to copy hashes.0000.rdat , diffs.0000.rdat , bodies.0048.cdat , receipts.0021.cdat , headers.0002.cdat , diffs.ridx , bodies.cidx , hashes.ridx , headers.cidx and receipts.cidx to replace your local files. I think it’s enough.

holiman commented Jul 15, 2020 •

I’ve uploaded some of it to s3. Install aws client, and try this:

So you should be able to replace your broken bodies.0000.cdat (all .0000. cdat/rdat files that are uploaded) with that^ .

The ones you should download are:

Hopefully, your indexes are correct and matches the offsets in the data files.

The only problem is the diffs.000.rdat . It never filled up the 2G limit, and thus won’t be identical to what you had. So what I think will happen is that it will truncate your data according to how many items are in diffs.0000.rdat .

I don’t think you will need to modify your idx files.

Note: this may well fail. It may even cause some of your existing ancient-data to become truncated (lost), but it might be worth a shot.

sssubik commented Jul 16, 2020 •

Hey I have not used AWS till now. When I try to run the command:
aws s3 cp s3://ancient-blockdata/diffs.0000.rdat .

It gives me: fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden

As I did some research looks like it needs a region parameter as AWS only allows download from a region based URL.
Could you provide me your region in AWS like:

aws s3 cp s3://ancient-blockdata/diffs.0000.rdat . **—region us-west-2b**

Or may be I need the permission to download the file.?
My Account name for AWS is ssubik

Hey @holiman may be I need the access through IAM User or is it Public?
Thanks

rjl493456442 commented Jul 16, 2020

btw @holiman I do think the indexes are corrupted. Like the last element in indexes are invalid.
If we can’t fix these indexes the data will be truncated anyway.

sssubik commented Jul 16, 2020 •

Hey @rjl493456442 I am also downloading a light client right now so that I can use the ethereum blockchain. I have simple question as to
Can I invoke a smart contract function through light client ipc at the backend?

Also the above aws command to download the files are not working.

rjl493456442 commented Jul 17, 2020

@sssubik Sure, light client should provide nearly all functionalities as the full node but it’s a little bit slower and unstable(need server connections).

sssubik commented Jul 17, 2020

Hey @holiman I think I need the access key to your s3 bucket. I cant seem to access it by any other means..
@rjl493456442 Thanks I will try it and query you if something comes up

sssubik commented Jul 20, 2020

Hey @rjl493456442 @holiman I cant download the files.. Could you help me please?

sssubik commented Jul 23, 2020 •

Hey @rjl493456442 I am syncing new fast node in another data directory right now. I tried copying to my previous working GETH fast node the following:
cp -f bodies.0000.cdat /home/user/.ethereum/geth/chaindata/ancient/bodies.0000.cdat
And I did this for:

But I again got this:

Still the same error persists. Is there some alternatives to this. Also I could not access the AWS so, I just copied the files from my new node.

sssubik commented Jul 23, 2020 •

I tried something in hope of fixing the issue. Where I copied
diffs.ridx, bodies.cidx, hashes.ridx, headers.cidx and receipts.cidx
from New Fast node into the old node. I think all indexes have truncated and I get this:

It was a shot in the dark as I am not getting much help. So is there any fix here?

rjl493456442 commented Jul 23, 2020

Are you sure your new node is synced?

sssubik commented Jul 23, 2020

Hey @rjl493456442 No the node was not synced.. I just copied those files as they were the same size

rjl493456442 commented Jul 23, 2020

Please wait until your new node’s chain is at least higher than 10329515. Then copy these files.

• hashes.0000.rdat
• diffs.0000.rdat
• bodies.0000.cdat
• receipts.0000.cdat
• headers.0000.cdat
• bodies.0048.cdat
• headers.0002.cdat
• receipts.0021.cdat
• diffs.ridx
• bodies.cidx
• hashes.ridx
• headers.cidx
• receipts.cidx

Hopefully the issue can be fixed.

sssubik commented Aug 4, 2020 •

Hey @rjl493456442. I am syncing the GETH node but I have worries that this kind of problem could repeat again. Does backing up the GETH node (Whole chaindata) by using some backup mechanisms like rsync help to restart the GETH node if the node goes down again?
Hey @rjl493456442 Any help would be appreciated. Thanks

FrankyHo commented Nov 14, 2020

Hi @sssubik did you fix the problem? I got problem after server reboot

tommymcguiver commented Dec 15, 2020 •

If you remove the 0 length files they come right back. Then you get the EOF error.

avatar-lavventura commented Dec 25, 2020

I am having the same problem. Only solution that I applied was removing the /private/geth folder and downloading complete chain all over again.

nuliknol commented Feb 15, 2021

One unclean shutdown due to power outage, and 2 months of download are gone! Damn it. How come you guys didn’t test the software for unclean shutdown? Very bad!

nuliknol commented Feb 15, 2021

I am having the same problem. Only solution that I applied was removing the /private/geth folder and downloading complete chain all over again.

that is NOT the solution

nuliknol commented Feb 15, 2021

Hi @sssubik did you fix the problem? I got problem after server reboot

the best solution is to fire the engineers who wrote this code and hire some good ones

avatar-lavventura commented Feb 15, 2021

I am having the same problem. Only solution that I applied was removing the /private/geth folder and downloading complete chain all over again.

that is NOT the solution

I understand your frasturation. Did you have any backup for your 2 months of download to recover from?

It was the only solution I come up with which worked on my end (I know its not that efficient) . Since I was working on a private chain it was only few GBs so it took 20 minutes to sync. But I believe it won’t be the case for the ethereum mainnet with which is around

karalabe commented Feb 16, 2021

@nuliknol Geth should be able to survive crashes just fine, perhaps with minimal data loss that can be recovered from the network. In your specific case, files that Geth wrote contain all zeroes. Any explanation for the data files turning into all 0?

nuliknol commented Feb 20, 2021 •

@nuliknol Geth should be able to survive crashes just fine, perhaps with minimal data loss that can be recovered from the network. In your specific case, files that Geth wrote contain all zeroes. Any explanation for the data files turning into all 0?

yeah, one explanation could be this:

3.1. Disk drives that do not honor sync requests
Unfortunately, most consumer-grade mass storage devices lie about syncing. Disk drives will report that content is safely on persistent media as soon as it reaches the track buffer and before actually being written to oxide. This makes the disk drives seem to operate faster (which is vitally important to the manufacturer so that they can show good benchmark numbers in trade magazines). And in fairness, the lie normally causes no harm, as long as there is no power loss or hard reset prior to the track buffer actually being written to oxide. But if a power loss or hard reset does occur, and if that results in content that was written after a sync reaching oxide while content written before the sync is still in a track buffer, then database corruption can occur.

USB flash memory sticks seem to be especially pernicious liars regarding sync requests. One can easily see this by committing a large transaction to an SQLite database on a USB memory stick. The COMMIT command will return relatively quickly, indicating that the memory stick has told the operating system and the operating system has told SQLite that all content is safely in persistent storage, and yet the LED on the end of the memory stick will continue flashing for several more seconds. Pulling out the memory stick while the LED is still flashing will frequently result in database corruption.

Note that SQLite must believe whatever the operating system and hardware tell it about the status of sync requests. There is no way for SQLite to detect that either is lying and that writes might be occurring out-of-order. However, SQLite in WAL mode is far more forgiving of out-of-order writes than in the default rollback journal modes. In WAL mode, the only time that a failed sync operation can cause database corruption is during a checkpoint operation. A sync failure during a COMMIT might result in loss of durability but not in a corrupt database file. Hence, one line of defense against database corruption due to failed sync operations is to use SQLite in WAL mode and to checkpoint as infrequently as possible.

my advice: hire a specialized guy in database development , because this freezer stuff looks very amateur coding. How it is possible that the headers file got reset ? The linux kernel did that? I don’t think so.
That’s why databases first write to WAL (Write Ahead Log) all the transactions, and they make it persistent with fsync(). After WAL is written the engine replays all the transactions on tables and does lots of write()s but these can go without fsync() because the WAL already got the update. Your append()s are not very safe code from the point of view of the design. What if the disk writes the data incompletely, how can you guarantee integrity ? Do you have checksums ? No.That’s why an expert in databases will do much better work, preferably a C language guy from linux kernel or OS dev community. I also doubt you did any tests of unclean shutdowns, because I only had about 3 unclean shutdowns on my Archival node (power outage) and the third time I am catching this!! If you would ran dedicated tests for unclean shutdowns (something a specialized database developer will always do because he understands how critical the DURABILITY of ACID is) we, users of geth would never experience such problems. I get power outages all the time, and my linux box restores everything like nothing happened. It is only the apps that are not storing the data in a DURABLE way get in troubles.

For the sake of documentation I am attaching what exactly went wrong and how I fixed it, so other people can have some clues on what to do. Basically I had to replace the headers file (because it got truncated to 0) and the hashes file (from a node that is already in sync).

Источник