Blog Urbit Troubleshooting

Errors and Troubleshooting

See this blog post for a comprehensive step-by-step troubleshooting process for the most common problems.

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.17 is current as of January, 2023. 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)!

Https stopped working

There was a small bug that has been fixed with certificate renewal.

You may need to run this command to clear the old certificate and then rerun the acme command.

|pass [%e %rule %cert ~]

When I update my binary, my urbit defaults to port 8080 instead of port 80

Linux users need to run this command in a terminal window to access your urbit on port 80 every time you upgrade your runtime (otherwise it'll default to port 8080). Replace [pier] with the location of your pier (the folder with your planet name)

sudo apt-get install libcap2-binsudo setcap 'cap_net_bind_service=+ep' [pier]/.run

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

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

Running |bump will suspend these apps and then retry the update.

|bump

loom: patch page partial write: 4096  Assertion failed:  0 (/pkg/noun/events.c: _ce_patch_write_page: 591

This is an error that basically means "your hard drive is full".  Looks for a core file from a crash that you can delete or try running |chop to cut down on your log file size.  

lockfile /root/*pier*/.vere.lock is corrupt! Assertion '0' failed: 0 (pkg/vere/disk.c: u3_disk_acquire: 615) Aborted (core dumped).

This also happens when the hard drive is full.  In most cases you can delete the lock file.

rm *pier*/.vere.lock

If you are on a VPS you will need to temporarily resize your VPS to be bigger if your hard drive is filled up.  To prevent this from happening in the future, you can create a 1GB file of random data in the urbit directory.  Then if your hard drive fills up, you can delete this file to temporarily have 1GB more space.

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.

bail: evil

"bail: evil" means someone is sending you packets signed with an invalid key. One interpretation is that someone breached and is attempting to message you with a new ship before your Azimuth has caught up to the newest state and has his new key. It doesn't have to be a breach, though - also could just be key rotation (breach implies key rotation, but key rotation does not imply breach)

No account connected

IF you get "No account connected" when you are interacting with bridge, that means you're not properly connected to your Metamask instance. This is not a bug in bridge.

Check these:

1. Are you logged into the correct address in Metamask, and do you have the green "Connected" message?
2. Do you have the right eth address? Is your planet at that address?
3. If you are using Brave browser, try a different browser.
4. Completely close your browser and start over.
5. Clear your cache.

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

./[pier]/.run pack

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.

./[pier]/.run meld

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 (ethereum) block number is stuck at an old value

Running +azimuth-block in dojo results in a value less than 15.xxx.xxx. Make sure you have gotten the latest OTA update and run the following command:

-azimuth-load

My point is not getting over-the-air updates (OTA)

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

If you are still not able to upgrade you probably either need to use |bump to suspend apps that are not compatible with the upgrade or you need to upgrade your binary because it's out of date.

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 (slow, cannot join, stuck joining, won't load)

1. Make sure you are on the latest binary
2. Restart your browser/reload urbit
3. Stop your ship and restart
4. Run pack and meld (see above)
5. Try starting urbit with the -p flag (example ./urbit sampel-palnet -p 32123) and make sure that port is open and forwarded if necessary.
6. 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

First try pack and meld (see above). Alternately, 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.