Node Operator Bootstrapping Introduction & Guide 🤠

@Jared Question about permissions. I have noticed when I use the ./ without sudo, all those blocks that I get come in owned by user:group incognito:incognito, but then after I restart inc_mainnet_0 container and it eventually gets the remaining blocks to get me up to latest, then those blocks are owned by root:root . I assume because we usually start in the installer script with sudo ./ . My question is: some of my block *.ldb files are owned by incognito:incognito and some are owned by root:root, is this going to cause a problem at some point? Who (what user and group) should the proper owner of all *.ldb files be?

It should not have an impact on performance since the docker container is ran with root privileges so it can access from any user. I will update the post to put sudo before ./ so all files are owned by the same.

Is the data source updated automatically? When I use the script and download the shard data I noticed some shards are very far behind and requires hours and hours of syncing. Shard 7 is 500k blocks behind for example.

The bootstrap files offered by Incognito are updated every week on Monday. In the future we may increase the interval that these files are updated.

Weird. If I go through all downloads 00,0-7 and then start the node I get the following heights:

beacon 1936451  (19.2G download)
shard0 1556202  (36.5G download)
shard1 1566596  (13.2G download)
shard2 1930751  (10.4G download)
shard3 1629497  (15.0G download)
shard4 1929529  (14.6G download)
shard5 1511193   (9.2G download)
shard6 1659406  (12.1G download)
shard7 1427293  (11.2G download)

Only 3 of those are up to date, the rest are way behind. (started on fresh node with empty folder, on a new machine, so it’s not my old data).

Is this for a fullnode?

There are the amounts you should have after running bootstrap. Keep in mind those files are compressed.

Yeah, its for a fullnode. Looking at the output, that’s the same url it downloaded from and the sizes looks correct. It unpacked all of them without showing any errors.

1 Like

@Jared @Support Any reason why this isn’t working?

“wget && sudo chmod +x && sudo bash”

It just hangs…

We migrated some servers last week. We will send you new link for bootstrap later.

1 Like

@support Does this include the node monitor? That appears down right now.


May I, too, have the new URL?

The guide will be upgraded to reflect any changes made and we will comment here as well.

The original post was edited to update the bootstrap script to Version 1.5.


Version 1.5 - 6/9/2022 -

  • Added fullnode support with option 55.
  • Updated to the new bootstrap server.
  • Optimized downloading of dependencies and will only check once per run.
  • Bootstrap files will be updated daily to ensure users get back online as quickly as possible.

Keep watch for Version 2.0, as this version will support bootstrapping the new (currently beta) validator database modes.

1 Like

Hey @Jared. What’s the ETA for 2.0? Getting very close to needing a new server with more storage space.

If you are running out of storage space, I would suggest you use this community-made script.

It works wonders and will slash the amount of space used. :slight_smile:

Thanks but running that script is slightly past my abilities. If you have a “For Dummies” version or could show me that would be great.

Also, I’m having issues with the updated Bootstrap. Once I select the Shard, it deletes the data, runs the update, and then errors out and cancels. Any ideas?

Sure, I sent you a PM. I can help walk you through it there.

Let’s also look over that via the PM.


Is it just me or something is wrong with the bootstrap server from where the script pulls the source file? I get the following when running the script:

Initializing download:
Too many redirects.

And if I try to get to the - looks like the last dump stopped on Aug 4th, 2022?

The devs are currently working on providing bootstrap files with State Pruning so users don’t have to do this as it can be taxing on the CPU for each shard.

1 Like


Regarding your advanced instructions like the above when copying from one of our healthy nodes to a problematic one. When there are lots of block files, the above command returns an error with “argument list too long”.

What alternative ways do you suggest for copying large numbers of block files from (a) from one folder to another on same server and (b) from one server to another server?

Or is there some workaround to allow “cp -v” command to have a larger argument list/number of files to handle?

Also, when manually copying data, must the entire contents (all files including the MANIFEST xxxxxx and CURRENT LOCK and LOG files) be copied with the .ldb files or are the .ldb files enough when inc_mainnet_0 is restarted?