Urbit Troubleshooting

U

Errors and Troubleshooting

Binary is out of date

Make sure your binary is the most recent version (If not using port)

You can tell what version your binary is when you start your ship. It's the first thing that prints. Version 1.8 is current as of January, 2022. To upgrade to the newest binary, just delete the current one and reinstall using the installation instructions. Do not delete your pier (the directory that has your planet or star name)!

bail:meme

(Sometimes accompanied by the following errors)

address out of loom!
Assertion '0' failed in noun/events.c:128
bail: oops
bailing out
pier: serf unexpectedly shut down

This means we ran out of memory on the loom (the persistent memory arena in urbit's runtime, currently limited to 2GB). This is currently always handled as a fatal error -- we're working on tooling to automatically recover where possible.

These are errors are sometimes ephemeral, since the loom holds both are persistent state and the "workspace" for processing a given event. In which case, restarting urbit is all that's required. But they usually recur, and require further intervention to be stopped.

Troubleshooting steps for solving this problem:

  1. Run |pack from the dojo - defragments the persistent state
  2. Run |meld (see below) - is a global deduplicator: it reallocates all persistent state off the loom, unifying any duplicate nouns it discovers along the way, and then copies them back to the loom.

Meld

Meld is a global deduplicator: it reallocates all persistent state off the loom, unifying any duplicate nouns it discovers along the way, and then copies them back to the loom. It uses all actual memory and not the 2 GB allocated to the loom. It also requires a lot of memory, perhaps multiples of the 2GB loom limit.

You can run meld from the dojo with |meld or you can run it from the linux command line

./urbit-worker meld pier-directory

If you get an error message "ur: hashcons: dict_grow: allocation failed, out of memory", when running meld, that means you don't have enough physical memory to run it. In such case you can do one of two things:

  1. You can copy your pier to another computer, run meld, and then copy it back.
  2. You can temporarily resize whatever VPS you are on to one with lots more memory.

kiln: OTA to %home failed, waiting for next revision from %kids on ~SOURCE

A merge conflict from upstream. If you don't have any local changes that you want to keep (e.g. hoon files and so on), you should be able to get up to date with the following two commands (replace SOURCE with wherever you're getting the ota from):

|merge %kids ~SOURCE %kids, =gem %only-that

followed by

|merge %home our %kids, =gem %only-that

It might take a while to process the update after issuing those.

My point is not getting ota's

To update from current host star:

|ota (sein:title our now our) %kids

To update from a random choice of Tlon servers:

|ota (snag (~(rad og eny) 5) `(list @p)`~[~wanzod ~marzod ~binzod ~litzod ~samzod]) %kids

When I try to ota on my planet from my star, I wind up with a base hash of xxxxx (my star has a base hash of yyyyy but a home hash of xxxxx and a kids hash of xxxxx). How can I make sure that updates flow down correctly from my star's galaxy?

Your star probably has some stale extra files. On the star, you can run

|merge %kids (sein:title our now our) %kids, =gem %only-that

and then

|merge %home our %kids

(you might need the =gem part on the second command as well)

That will align its kids desk with the parent galaxy, and then align its home desk with its kids desk.

  • Title is part of zuse (the standard library); it lets you query information about other ships (and yourself).
  • Sein is a function within title which lets you get the sponsor of a given ship - the parameters you give it are (afaik) \who are you \ when is it \ who do you want to know about. Not totally sure why you need to specify who you are, but it seems to break if you put in anything else for the first 'our'.
  • Our is just the current ship (if you type it into dojo on its own you'll get your ship name back).
  • Now is the current time.

So (sein:title our now our) is "who is my current sponsor" and `(sein:title our now~zod)`is "who is ~zod's current sponsor".


Error: dojo: generator failure

A generator is a one-shot script like +code or |hi. Generator failure probably means you submitted an invalid input. If it said dojo: nest-need / dojo: nest-have it means the input was of the wrong type. If it didn't say anything apart from the stack trace it probably intentionally crashed itself with a ?> test, again probably because of bad input anyway it shouldn't matter, generators crashing doesn't cause any problems.

Error: Derived networking keys do not match on chain details

The way networking key derivation works is as follows:

If you log in using a master ticket, we derive the networking keys from that (as defined in UP8, the urbit wallet spec).

If you log in using any other method, you sign a "Bridge authentication token" on-login, and we derive the networking keys from that instead.

The latter wasn't always the case. Up until July 2020, we used random networking keys for the second case, preventing Bridge from re-deriving the keyfile on future logins.

This message means that, for whatever reason, Bridge cannot derive the (networking) private keys that match the public ones registered on-chain. This is not a problem per se, it just means you cannot re-download the keyfile that you should be using right now.

If you've already booted your ship, fine, this is not a problem, because you don't need the file. If you still need to boot your ship, you can simply configure new networking keys, and those should be derivable by Bridge going forward, provided you use the same login details.

Groups is misbehaving (cannot join, stuck joining, won't load)

  1. Restart your browser/reload urbit
  2. Stop your ship and restart
  3. Try this: (halts the %group-view agent without preserving its state, and then restarts all of the %landscape desk) 
    |nuke %group-view
    |revive %landscape

Error: no such user or named directory: planet-name

You tried to boot Urbit by including the tilde in the planet name. Linux thinks you're referring to a user. Leave the tilde off.

Error: error fetching http://eth-mainnet.urbit.org:8545: HTTP 404

The Ethereum server crashed at Tlon. It's not your fault. Wait a little while and try booting again.

missing-subscription-in-unsubscribe

Harmless - it's along the lines of "a listener closed a connection we already dropped"

authenticated-without-cookie

Also harmless.


About the author

Jeremy Tunnell
I study Integral Theory and Zen Buddhism at Integral Zen.

Comments

Get in touch

You can reach Jeremy at [email protected]