Boot failed on macOS and (some subset of) Linux: "terminals database is inaccessible" #1369
Comments
|
Can't replicate this — a comet boots fine on my macOS. Have you given it another shot? I've had times with this release where I had to just try again and it would work. Otherwise there may be more variables to troubleshoot for this. |
|
Tried three times. Trying a fourth with |
|
Reproduced also with |
|
Some pre-emptive Googling does seem to suggest this type of error points to a local issue ...hmm. |
|
@matildepark tried |
|
This seems relevant: https://stackoverflow.com/questions/43130276/trouble-opening-ncurses-examples-in-os-x. |
|
Ah, turns out booting with |
|
I get this if I try to resolve the urbit binary out of my Context: we're shipping a terminfo database in the release tarball due to what might be called "deficiencies" in our ncurses cross-compilation build. /cc @benjamin-tlon |
|
OK, I eventually solved this in a pretty complicated way. First, I had tried running I then got the idea that my From another answer somewhere, I learned those directory names, I think, should be the first letter of the terminfo files they contain. In this case, the directory Unfortunately, System Integrity Protection prevents me from modifying this folder, so I had to turn it off by rebooting into recovery mode (CMD+R on reboot) and running After rebooting, I was able to change If I understand correctly, this means I need to add |
|
I should also mention, this sunk my ship: |
|
That's not sunk! |
|
You hadn't computed anything, let alone communicated with anyone else. (Admittedly, this is not obvious criteria) |
|
OK – crashed. Anyhow, being conservative, I cycled keys, and now I'm getting key mismatches :) |
|
This complicated way (and various variations on it) is precisely what we're trying to avoid by shipping the terminfo database in our release tarball. And all that works if you run urbit with a relative/full path, instead of just The reason it doesn't work is that we're setting |
|
Presumably our ethereum node hasn't caught up to your configureKeys transaction. But that's just a guess, sorry. |
|
@joemfb it's a wild new world |
|
Did you download your new keyfile and use it? It looks to me like you're trying the old one.
…On Tue, Jul 23, 2019 at 12:06 AM, Morgan Sutherland < ***@***.*** > wrote:
@ joemfb ( https://github.com/joemfb ) it's a wild new world
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (
#1369?email_source=notifications&email_token=ABKLYGAREFOASIZ2GCSB4B3QA2UWHA5CNFSM4IGABYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2SELMY#issuecomment-514082227
) , or mute the thread (
https://github.com/notifications/unsubscribe-auth/ABKLYGEX5WTKNEHZRWT25B3QA2UWHANCNFSM4IGABYTQ
).
|
flowerornament
changed the title
|
@philipcmonk I did. As you mentioned in For sure I was using |
|
Quick note, it looks like, if @joemfb is correct, I was able to boot a comet with |
|
@joemfb This, btw, is why I wrote the ssl certificates to a temp file on startup. If you're going the static binary route, you really can't make any assumptions about paths, how the binary will be invoked, etc. |
|
I understand that, and was part of the discussion around those tradeoffs. How does that translate to a terminfo database? Do you think we should embed a tarball of the $TERMINFO_DIR in the binary? I think that this is all just avoiding the problem of actually correctly cross-compiling ncurses. I believe all our target platforms already have a terminfo database at a predictable location, and we just need to build in such away as to be compatible with said database. But I haven't verified these things, and I don't know how, other than just diving in. |
|
Oh crap, I didn't realize the database wasn't a single file. Sorry for the noise. (But embedding libtar and a tar file is an option, I suppose.) Also, there's a person on Twitter running into this same issue. |
|
We should have an installation script?
We already need the urbit and urbit-worker processes to be co-located, so
bundling things into the executable doesn't help that much.
…On Tue, Jul 23, 2019 at 11:01 AM Elliot Glaysher ***@***.***> wrote:
Oh crap, I didn't realize the database wasn't a single file. Sorry for the
noise. (But embedding libtar and a tar file is an option, I suppose.)
Also, there's a person on Twitter running into this same issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1369?email_source=notifications&email_token=AKDFPEWZUN54J7DPAAHQPM3QA5BQTA5CNFSM4IGABYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2T6GII#issuecomment-514319137>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKDFPEXNTFXLWJUY6CT7QGLQA5BQTANCNFSM4IGABYTQ>
.
--
~pitmug-roptec
https://urbit.org
|
|
The standard approach to this is to generate a wrapper script that sets
environment variables and then invokes the executable.
…On Tue, Jul 23, 2019 at 12:17 PM Benjamin Summers ***@***.***> wrote:
We should have an installation script?
We already need the urbit and urbit-worker processes to be co-located, so
bundling things into the executable doesn't help that much.
On Tue, Jul 23, 2019 at 11:01 AM Elliot Glaysher ***@***.***>
wrote:
> Oh crap, I didn't realize the database wasn't a single file. Sorry for
> the noise. (But embedding libtar and a tar file is an option, I suppose.)
>
> Also, there's a person on Twitter running into this same issue.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1369?email_source=notifications&email_token=AKDFPEWZUN54J7DPAAHQPM3QA5BQTA5CNFSM4IGABYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2T6GII#issuecomment-514319137>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKDFPEXNTFXLWJUY6CT7QGLQA5BQTANCNFSM4IGABYTQ>
> .
>
--
~pitmug-roptec
https://urbit.org
--
~pitmug-roptec
https://urbit.org
|
|
btw I believe this is caused by the `urbit` binary not being able to find
`urbit-terminfo` (which was also included in the release tarball).
Inelegant, but we're working on a nicer fix.
THe best thing to do in the short term is to follow the install
instructions _exactly_ (don't move anything after untar and use `./urbit`
(with leading dot fas) to invoke).
—
~poldec-tonteg
http://urbit.org
…On Thu, Jul 25, 2019 at 3:22 AM Predicat ***@***.***> wrote:
I have the same problem on both macOS Mojave and Linux Mint 19.1.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1369?email_source=notifications&email_token=AAMJBY7CZEYGQ5MWDSF7T7TQBD56HA5CNFSM4IGABYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2YBR7I#issuecomment-514857213>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMJBYYTG7W7CCII7Z2M4JDQBD56HANCNFSM4IGABYTQ>
.
|
|
I got this issue having untar-ed It might be worth adding some instructions to the docs to suggest booting the ship in the same place you extracted the urbit binaries. |
|
My solution is via aliases. Here's how I have setup mine on my ubuntu server: First, I have 2 shell scripts to handle the wrapping. One is for normal urbit runs, the other is a simple update manager. urbit.sh #!/usr/bin/env bash
cd -P ~/urbit/latest
./urbit $@urbit-install.sh #!/usr/bin/env bash
if [ "$1" = "" ]
then
# missing version number argument
echo 'Must provide a version number (eg. 0.8.1)'
exit 1
fi
if [ ! -d ~/urbit/$1 ]
then
# version directory doesn't exist, attempt to download
mkdir -p ~/urbit/$1
cd ~/urbit/$1
curl -O https://bootstrap.urbit.org/urbit-linux64-v$1.tgz
tar xzf urbit-linux64-v$1.tgz
if [ ! -e ~/urbit/$1/urbit ]
then
# tarball failed, clean up files
echo Failed to get Urbit v$1
rm -rf ~/urbit/$1
exit 1
fi
echo Installation complete for version $1
else
echo Version $1 is already installed.
fi
# update symlink
ln -sf ~/urbit/$1 ~/urbit/latest
echo Active version set to: $1I have stored these in my alias urbit="sh ~/bin/urbit.sh $@"
alias install-urbit="sh ~/bin/urbit-install.sh $@"These in combination will use the ~/urbit directory for referencing all the things. The ~/urbit/latest points to the active version And it boots for me just fine. |
|
I ran into the same issue just now booting my ship for the first time, running Linux 64-bit (Manjaro) with the latest updates. Navigating bash into the directory that the urbit binary was located in ended up working. |
|
@benjamin-tlon what is the status on this fix? |
|
I messed around with this a bit more and realize my comment above was inaccurate. Here's 5 possible cases and their outcome. A fake zod already exists. Context 1: Context 2: The second context seems related but I can't know for sure. There doesn't seem to be an issue open for it that I can see. EDIT: Realized I wasn't being clear saying "bash is in" - the bash binary is in |
|
Was just checking on NixOS/nixpkgs#65301 and noticed it was closed pending resolution of this issue. |
drbeefsupreme
changed the title
|
This is fixed in #3064. |
The text was updated successfully, but these errors were encountered: