Blog Urbit Troubleshooting

Jeremy Tunnell at

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.10 is current as of August, 2022. To upgrade to the newest binary, see how to upgrade your urbit binary. Do not delete your pier (the directory that has your planet or star name)!

OTA blocked on {%bitcoin, %urchatfm, %auth-id, %etc...}

Your OTA is not applying because some apps are blocking it.

You can suspend these apps and then retry the update. See a complete list of dojo commands here.

|suspend %bitcoin

curl: error https://bootstrap.urbit.org/vere/once/last: HTTP 403
vere: unable to check for next version

The upgrade mechanism supports release channels -- the normal release pace is live. Your pier is on the "once" channel (ie, one-off-build, not a release), due to a bug in the v1.9 tarball build process.

You can change the channel by editing *pier*/.bin/pace without having to redock. Change "once" to "live" in the following file.

pico *pier*/.bin/pace

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 (see below) - 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.

Pack

Pack is a quick utility to reclaim some memory.

You can run pack from the dojo with |pack or you can run it from the linux command line on version 1.9 and up. Replace [pier] with the location of your pier, which is the folder that is named after your planet.

./[pier]/.run pack (after version 1.9)

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. Replace [pier] with the location of your pier, which is the folder that is named after your planet.

./urbit-worker meld  (pre version 1.9)
./[pier]/.run meld (after version 1.9)

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.

My azimuth block number is stuck at an old value

Running +azimuth-block in dojo results in a value either 13.xxx.xxx or 14.xxx.xxx. The current value is somewhere around 15.xxx.xxx. Make sure you have gotten the latest OTA update and run the following command:

-azimuth-load

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.

after downloading %graph-query, unable to access the dojo via terminal from Landscape - it just continually says it's 'connecting...' but never opens

Try suspending and resuming the terminal app.

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 starting urbit with the -p flag (example ./urbit sampel-palnet -p 32123) and make sure that port is open and forwarded if necessary.
  4. Try this: (halts the %group-view agent without preserving its state, and then restarts all of the %landscape desk)
    |nuke %group-view
    |revive %landscape

My urbit is slow or generally takes a long time to send messages/join groups

It's possible that your ames port is not open and are having to route all communication through your galaxy. See here: Troubleshooting Urbit ames routing issues

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.


Add Comment