Urbit fails to boot

[dbohdan]

• A brief description

Urbit 0.4.3, "a secure peer-to-peer network of personal servers, built on a clean-slate system software stack", fails to boot on WSL. It boots correctly on Ubuntu 14.04.

• Expected results

Urbit creating a new "comet" (identity), connecting to the network, downloading data and showing the command prompt.

• Actual results (with terminal output if applicable)

Urbit hangs at the point you see in the log below.

$ urbit -c temp_comet
[...]
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/ames:<[1.221 17].[1.227 34]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/ames:<[1.222 17].[1.227 34]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/ames:<[1.223 17].[1.227 34]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/ames:<[1.224 17].[1.227 34]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/ames:<[1.224 21].[1.224 66]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/ames:<[1.224 25].[1.224 66]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/ames:<[1.224 31].[1.224 65]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[946 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[947 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[948 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[949 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[950 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[951 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[952 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[952 11].[952 49]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[952 15].[952 49]>
<awaiting hood, this may take a few minutes>

• Your Windows build number

Microsoft Windows [Version 10.0.14393]

• Steps / All commands required to reproduce the error from a brand new installation

wget https://media.urbit.org/dist/debian/urbit_0.4.3-1_amd64.deb
sudo dpkg -i urbit_0.4.3-1_amd64.deb
sudo apt-get update
sudo apt-get install -f -y
urbit -c ~/mycomet

The following Vagrantfile sets up an Ubuntu 14.04 VM in VirtualBox where the command urbit -c ~/mycomet works as expected.

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/trusty64"

  config.vm.provider "virtualbox" do |vb|
    vb.memory = 512 + 2048
    vb.cpus = 1
  end

  config.vm.provision "shell", inline: <<-SHELL
    wget https://media.urbit.org/dist/debian/urbit_0.4.3-1_amd64.deb
    sudo dpkg -i urbit_0.4.3-1_amd64.deb
    sudo apt-get update
    sudo apt-get install -f -y
  SHELL
end

• Strace of the failing command

Too large to paste or attach on GitHub. You can download it from https://ipfs.io/ipfs/QmbjRAMgLm9xXW539AfHfXMwXV6o6b9GCsLkTjeyJB3PE1.

In case it may be helpful, here is an strace of Urbit operating correctly on Ubuntu 14.04: https://ipfs.io/ipfs/QmWgdzvTz2uB54eBdBwHF7nWReQGWemnnfdzWCuhcCHkCR.

• Required packages and commands to install

See the steps to reproduce above.

[therealkenc]

Below is the tail end of the linked ubuntu-correct.strace (those turn out to be zip files for anyone playing along). The code loops pathologically on /proc/self/maps, segfaulting (it appears by design) on every turn. 2.8 million syscalls on native, with half a million of those being to mprotect() alone. 29,000 segfaults.

Anyway, I am guessing but have not confirmed this is #708 (I haven't installed it). You can confirm by running "strace -tt -ff -o urbit.strace urbit -c ~/mycomet" and pasting the first few lines of one of the read /proc/self/maps turns. I could be wrong.

There doesn't seem to be anything resembling a command prompt in the native strace linked; it ends midway through a turn. I could have missed it in the noise though. The WSL strace looks the same, but ends with a mercy SIGKILL, presumptively because #708 will cause this to take forever.

Since we're here, I'd like to renew my humble request to stub a 'p' in the protection bits. With all the fixes recently, that is one of the few remaining identified problems (contrast 'only' problems) with electron.

Native:

[...at this point we're near the end of a /proc/self/maps pass]
read(19, "08:01 5284                      "..., 1024) = 1024
read(19, "f000 r-xp 00000000 08:01 2112   "..., 1024) = 1024
read(19, "1720de6000 ---p 001b3000 08:01 2"..., 1024) = 1024
read(19, "7f1721291000-7f1721292000 r--p 0"..., 1024) = 474
close(19)                               = 0
mprotect(0x38a18000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn()                          = 3231041697
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x37e0e120} ---
[...and now starting another pass]
open("/proc/self/maps", O_RDONLY)       = 19
read(19, "00400000-004f2000 r-xp 00000000 "..., 1024) = 1024
read(19, "00000 00:00 0 \n363a4000-363a8000"..., 1024) = 1024
read(19, "000000 00:00 0 \n36464000-3646800"..., 1024) = 1024
[...snip]
read(19, " \nb1300000-b1308000 r--p 0000000"..., 1024) = 1024
read(19, "0 \nb2a50000-b2cb8000 r--p 000000"..., 1024) = 1024
read(19, "           /lib/x86_64-linux-gnu"..., 1024) = 1024
read(19, ":01 2261                       /"..., 1024) = 1024
[...snip]
read(19, "/x86_64-linux-gnu/libcurl-gnutls"..., 1024) = 1024
read(19, "                       /lib/x86_"..., 1024) = 1024
read(19, "265                       /lib/x"..., 1024) = 1024
read(19, "721286000 rw-p 00000000 00:00 0 "..., 1024) = 556
close(19)                               = 0
mprotect(0x37e0c000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn()                          = 3232263176
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x3991bbc8} ---
[...and again]
open("/proc/self/maps", O_RDONLY)       = 19
read(19, "00400000-004f2000 r-xp 00000000 "..., 1024) = 1024
read(19, "00000 00:00 0 \n363a4000-363a8000"..., 1024) = 1024
read(19, 
[the linked native strace ends here]

Tail end of strace on WSL:

read(19, "-7f89bead4000 rw-- 00003000 00:0"..., 1024) = 1024
read(19, ".9\n7f89bef40000-7f89befac000 r-x"..., 1024) = 1024
read(19, "5000 r-x- 00000000 00:00 222518 "..., 1024) = 1024
read(19, "f0000-7f89bf9f1000 rw-- 00000000"..., 1024) = 1006
close(19)                               = 0
mprotect(0xb5b94000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn()                          = 3048290428
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0xb5b98000} ---
open("/proc/self/maps", O_RDONLY)       = 19
read(19,  <unfinished ...>
+++ killed by SIGKILL +++

[dbohdan]

@therealkenc

There doesn't seem to be anything resembling a command prompt in the native strace linked; it ends midway through a turn.

Oops. Looks like I truncated the strace before the prompt. It looks like this when Urbit gets to it:

write(0, "\33[49m\33[39m~dosheb_digwex:dojo> \33"..., 61) = 61
write(0, "\r", 1)                       = 1
write(0, "\33[K", 3)                    = 3
write(0, "\33[49m\33[39m~dosheb_digwex:dojo> \33"..., 61) = 61
write(0, "\r", 1)                       = 1
write(0, "\33[K", 3)                    = 3
write(0, "\33[49m\33[39m~dosheb_digwex:dojo> \33"..., 61) = 61
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [PROF], 8) = 0

Here is the output from strace -tt -ff -o urbit.strace urbit -c ~/mycomet:

[...]
23:35:29.030917 open("/proc/self/maps", O_RDONLY) = 15
23:35:29.030917 read(15, "00400000-004f2000 r-x- 00000000 "..., 1024) = 1024
23:35:29.124928 read(15, " /lib/x86_64-linux-gnu/libnss_fi"..., 1024) = 1024
23:35:29.125925 read(15, "7fd27805a000-7fd278088000 rw-- 0"..., 1024) = 1024
23:35:29.125925 read(15, "    /usr/lib/x86_64-linux-gnu/li"..., 1024) = 1024
[...]
23:35:29.open("/proc/self/maps", O_RDONLY) = 15
23:35:29.127923 read(15, "00400000-004f2000 r-x- 00000000 "..., 1024) = 1024
23:35:29.219928 read(15, " /lib/x86_64-linux-gnu/libnss_fi"..., 1024) = 1024
23:35:29.219928 read(15, "7fd27805a000-7fd278088000 rw-- 0"..., 1024) = 1024
23:35:29.219928 read(15, "    /usr/lib/x86_64-linux-gnu/li"..., 1024) = 1024
[...]

In this case there is a consistent delay of circa 94 ms after each first read() from a new file descriptor for /proc/self/maps. Over the 7 minutes that I let Urbit run before I SIGKILLed it there were 1115 such delays for a total of ~103 seconds. On other runs I got comparable or smaller delays (≥10 ms). They aren't there on Ubuntu in a VM, but they aren't as bad as #708, either. It seems unlikely this is the cause of the problem.

I have found something else. Grepping a native strace for EINVAL finds just this line:

setrlimit(RLIMIT_NOFILE, {rlim_cur=10*1024, rlim_max=4*1024}) = -1 EINVAL (Invalid argument)

but on WSL you get

getrusage(0x1 /* RUSAGE_??? */, 0x7fffcfa085c0) = -1 EINVAL (Invalid argument)
setrlimit(RLIMIT_NOFILE, {rlim_cur=10*1024, rlim_max=2*1024}) = -1 EINVAL (Invalid argument)
getrusage(0x1 /* RUSAGE_??? */, 0x7fffcfa07440) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
bind(19, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)
[Etc. The line repeats hundreds of times.]

The setitimer() errors are related to #1577. @stehufntdev comments at #1577 (comment) saying that

WSL currently only supports ITIMER_REAL for setitimer.

However, if you replace ITIMER_VIRTUAL with ITIMER_REAL in Urbit's source code it takes care of the errors apparently without breaking anything else. (But it does not fix Urbit.) That leaves us with

socket(PF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 19
bind(19, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = -1 EINVAL (Invalid argument)

which is the same as one of the two errors you've pointed out for IPFS (#1666).

[therealkenc]

Informative follow-up; thank you. I should have included another stat in my original reply:

$ grep -E "$open\(\"/proc/self/maps\"" ubuntu-correct.strace | wc
  17553   70212  789885

But yeah even with 17k turns, if the initial reads are really only taking an average of ~10ms (as opposed to ~100ms), then you can't account for slowness there alone. Since there aren't that many calls between open-to-open, whatever is causing the delay should stick out. Actually the only real suspects are mprotect() and rt_sigreturn(). If you do tail -f <tracefile> in another terminal maybe it will be obvious.

[edit: 1671 isn't related...]
Keep an eye on #1671 too. I haven't looked at it in detail, but the attached strace has:

--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=1, si_uid=0, si_value=0} ---
rt_sigreturn()                          = -1 EINTR (Interrupted system call)

Which is different than your case, but you've got:

$ grep -E "$rt_sigaction\(SIGSEGV" ubuntu-correct.strace | wc
  25601  640025 4633784

It might just be similar enough if signal delivery is taking ages. That's highly speculative though.
[/edit]

That bind(AF_NETLINK, ...) is probably fatal anyway of course. But at least you'll know why it looks like a hang instead of getting some well-formed EINVAL related error message.

[dbohdan]

Thanks for the suggestion to follow the strace in real time with tail -f. I see that most of the time spent waiting is spent in the first read() for a descriptor, not mprotect() or rt_sigreturn(). There is also the occasional epoll_wait(), apparently on the standard input:

11:16:57.485958 epoll_ctl(8, EPOLL_CTL_MOD, 0, {EPOLLIN, {u32=0, u64=0}}) = 0
11:16:57.485958 epoll_wait(8, [], 1024, 18000) = 0
11:17:15.487346 clock_gettime(CLOCK_MONOTONIC_COARSE, {518, 24910000}) = 0

A correction about the delays: they have actually all been 100±10 ms. I got lower delays when I parsed an strace file wrong.

But at least you'll know why it looks like a hang instead of getting some well-formed EINVAL related error message.

It looks like this wasn't a proper hang to begin with. If I let Urbit sit there long enough after it prints

/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[952 7].[956 50]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[952 11].[952 49]>
/~rep/home/~2017.1.13..02.56.39..7e35/arvo/zuse:<[952 15].[952 49]>

it restarts from with the message recover: dig: over on the standard error and goes until it gets to the point where it "hangs".

I've also noticed that the bind() EINVAL error happens only once per run, right after Urbit is started. The bind() isn't retried. That could either mean that whatever it uses that bind() for is optional, or that it doesn't stop on what should be a fatal error.

[therealkenc]

Okay. If we use your original 94ms, that works out to ~1650 seconds or ~27.5 minutes for 17553 turns, all things being equal.

I wouldn't overthink the bind(). If you are tenacious enough you could force-fail it in Urbit's source on Real Linux and see what happens, but at this point, smacks of effort to me. Fatal or not, it's a known issue.

[dbohdan]

I have found the source of the failing bind() and simulated it failing on Real Linux. It was in the bundled libuv. In an Ubuntu VM Urbit boots fine even when that bind() is never called. Here's the patch:

--- ./outside/libuv-v1.7.5/src/unix/android-ifaddrs.c.orig   2017-02-06 21:10:52.429272192 +0200
+++ ./outside/libuv-v1.7.5/src/unix/android-ifaddrs.c        2017-02-06 21:11:32.353272603 +0200
@@ -45,48 +45,12 @@

 static int netlink_socket(void)
 {
-    struct sockaddr_nl l_addr;
-
-    int l_socket = socket(PF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
-    if(l_socket < 0)
-    {
-        return -1;
-    }
-
-    memset(&l_addr, 0, sizeof(l_addr));
-    l_addr.nl_family = AF_NETLINK;
-    if(bind(l_socket, (struct sockaddr *)&l_addr, sizeof(l_addr)) < 0)
-    {
-        close(l_socket);
-        return -1;
-    }
-
-    return l_socket;
+    return -1;
 }

 static int netlink_send(int p_socket, int p_request)
 {
-    char l_buffer[NLMSG_ALIGN(sizeof(struct nlmsghdr)) + NLMSG_ALIGN(sizeof(struct rtgenmsg))];
-
-    struct nlmsghdr *l_hdr;
-    struct rtgenmsg *l_msg;
-    struct sockaddr_nl l_addr;
-
-    memset(l_buffer, 0, sizeof(l_buffer));
-
-    l_hdr = (struct nlmsghdr *)l_buffer;
-    l_msg = (struct rtgenmsg *)NLMSG_DATA(l_hdr);
-
-    l_hdr->nlmsg_len = NLMSG_LENGTH(sizeof(*l_msg));
-    l_hdr->nlmsg_type = p_request;
-    l_hdr->nlmsg_flags = NLM_F_ROOT | NLM_F_MATCH | NLM_F_REQUEST;
-    l_hdr->nlmsg_pid = 0;
-    l_hdr->nlmsg_seq = p_socket;
-    l_msg->rtgen_family = AF_UNSPEC;
-
-    memset(&l_addr, 0, sizeof(l_addr));
-    l_addr.nl_family = AF_NETLINK;
-    return (sendto(p_socket, l_hdr, l_hdr->nlmsg_len, 0, (struct sockaddr *)&l_addr, sizeof(l_addr)));
+    return -1;
 }

 static int netlink_recv(int p_socket, void *p_buffer, size_t p_len)

[therealkenc]

Probably not the right patch. See libuv's gyp file here. [Unless Urbit on Ubuntu is picking up Android stuff?]

Anyway it looks like NETLINK_ROUTE is fixed as of 15007+ #468 (message). Silly I missed that. I also didn't pick up that you are on Anniversary Update (14393). Best bet at this point is to upgrade to insider builds. That won't address #708 mind, but you'll be on more solid footing.

[dbohdan]

Probably not the right patch.

You're right. I spoke too soon. Looks like the bind() was missing from the strace after I recompiled with the patch for other reasons (creating a new comet vs. starting an existing one?).

I'll try 15007 and get back to you.

[juped]

A comet does talk to the network pretty early. If you want an independent startup, the process is a little more involved, but basically: have the maint-20160818 branch of https://github.com/urbit/arvo checked out somewhere, get https://bootstrap.urbit.org/latest.pill, and start up with urbit -c -F -I zod -A arvo/ -B latest.pill zod - more detailed info at http://urbit.org/fora/posts/~2017.1.5..21.31.04..20f3~/.

[sunilmut]

@dbohdan - Please let us know if this still repro's for you on 15007+? Thanks for trying out WSL.

[therealkenc]

@sunilmut - Yes this reproduces on 15046. The problem here isn't NETLINK_ROUTE. On the terminal you get:

...
<awaiting hood, this may take a few minutes>

...except it isn't going to take a few minutes. To a user it just hangs forever, because it progresses too slowly. Repro is:

sudo apt-get install libsigsegv-dev libuv-dev libgmp3-dev
wget https://media.urbit.org/dist/debian/urbit_0.4.3-1_amd64.deb
sudo dpkg -i urbit_0.4.3-1_amd64.deb   # might have to add more deps if I missed any above
mkdir strace
strace -tt -ff -o strace/urbit urbit -c temp_commit

Eventually it will start looping on the following pattern:

...
13:00:47.841911 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0xb57d7fd4} ---
13:00:47.841992 open("/proc/self/maps", O_RDONLY) = 19
13:00:47.842145 read(19, "00400000-004f2000 r-x- 00000000 "..., 1024) = 1024
13:00:47.902094 read(19, "00:00 0\n3642c000-36430000 r--- 0"..., 1024) = 1024
...
13:00:47.910928 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0xb57d3ff4} ---
13:00:47.910969 open("/proc/self/maps", O_RDONLY) = 19
13:00:47.911114 read(19, "00400000-004f2000 r-x- 00000000 "..., 1024) = 1024
13:00:47.971731 read(19, "00:00 0\n3642c000-36430000 r--- 0"..., 1024) = 1024
... [more of the same]

There's also an EINVAL on setitimer() earlier on:

setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = -1 EINVAL (Invalid argument)

...but I doubt that's the core problem here. Marking this issue with label 'network' is premature at best. My money is on #708, but you be the judge.

[dbohdan]

@sunilmut You're very welcome! I really like WSL. It's a major reason I use Windows on a daily basis again. I plan on doing more testing when the Creators Update comes out.

(I intended to test on 15007+ earlier, but development VMs won't receive Fast Ring updates for me and I don't want to run an Insider Build on my desktop/laptop since you can't go back to stable without reinstalling. Maybe you don't get those updates in Windows 10's evaluation mode?)

@therealkenc Regarding setitimer(): as I wrote before, replacing ITIMER_VIRTUAL with ITIMER_REAL apparently makes no difference to Urbit being able to run on WSL. I want to add that the same is true on Linux: this change doesn't seem to break anything.

[sunilmut]

@dbohdan - Apologize for the delayed response. I tried your repro steps (below) on a recent dev build of WSL and the results I am seeing seem to match that of native Ubuntu. I am not an urbit expert, so I am not sure what to expect, but it seems to be working for me in recent builds (should be working in latest insider builds as well).

Are you able to try your repro on the latest Windows Insider build? If not, you can wait for the Creators Update release, which should be very soon.

wget https://media.urbit.org/dist/debian/urbit_0.4.3-1_amd64.deb
sudo dpkg -i urbit_0.4.3-1_amd64.deb
sudo apt-get update
sudo apt-get install -f -y
urbit -c ~/mycomet

[therealkenc]

@sunilmut - That is a screencap of Urbit promising to return in "a few minutes". You only made it to '~zod is your neighbour'. Note I don't use Urbit and had never heard of it before the OP. I've only run it out of curiosity. On Real Linux you get to the Urbit prompt in a few minutes. I have never waited for enough multiples of a "few minutes" see it get to a prompt on WSL. This is on 15061, natch.

Success on Real Linux looks something like below.

ken@yakkety-vm:~$ urbit -c ~/mycommet
~
urbit 0.4.3
urbit: home is /home/ken/mycommet
loom: mapped 2048MB
boot: installed 239 jets
fetching https://bootstrap.urbit.org/latest.pill to /home/ken/mycommet/.urb/urbit.pill
boot: loading /home/ken/mycommet/.urb/urbit.pill
arvo: time: ~2017.3.22..05.21.47..2c99
generating 2048-bit RSA pair...
saving passcode in /home/ken/mycommet/.urb/code.~ribnyt-mogpun
(for real security, write it down and delete the file...)
ames: czar zod.urbit.org: ip .104.197.214.171
ames: on localhost, UDP 35022.
http: live (insecure, public) on 8080
http: live ("secure", public) on 8443
http: live (insecure, loopback) on 12321
; ~zod not responding still trying
; ~zod is ok
; ~zod is your neighbor
[%dill-init ~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet %hood]
      activated sync
    from %base
  on ~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet
to %home
      sync succeeded
    from %base
  on ~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet
to %home
>> [%mo-not-running %talk %peer]
>> [%mo-not-running %dojo %peer]
'initial merge succeeded'
[~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet, driving ~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet]
activated app base/dojo
activated app base/talk
[linked to [p=~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet q=%talk]]
--------------| new journal %public: visible activity
--------------| new mailbox %porch: default home
--------------| cap default home
--------------| met ~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet %h
[linked to [p=~ritsyd-wallug-silrus-lagrul--bidnup-racsur-fadrud-patwet q=%dojo]]
~ritsyd_patwet:dojo> 

[dbohdan]

@sunilmut I've given up on getting the evaluation VM to update, so I'm waiting for the Creators Update to come out. As @therealkenc says, that screenshot doesn't show a success. On 14393 Urbit fails after the output in the screenshot.

[EricGrahamMacEachern]

@dbohdan I tried it on the Creators Update and it doesn't work there either. See my post linked in this thread.

[therealkenc]

@dbohdan - might want to give this another try on FCU (16299) or better. #708 had improvements that will affect your scenario. I am not entirely convinced Urbit will run, mind, because I have a suspicion libsigsegv-dev is problematic on WSL (but nor can I prove that). But it worth a try and a new strace on the books would help.

[tara-raj]

Please try this on a newer build and let us know if you still run into this issue. If you can please provide more information when you do that would also be very helpful!

[therealkenc]

I am willing to bet Urbit still suffers from #3403 #2555 per previous comment

[Fang-]

Heads up, as mentioned in urbit/urbit#2611, urbit seems to run fine on WSL2.

[EricGrahamMacEachern]

Wow, I didn't know this became an ongoing thing. It's great that they fixed it. I've transitioned to nothing but Linux. Android watch, Android phone, Ubuntu laptop, Ubuntu Desktop, GoDaddy Linux web server etc.

[therealkenc]

Wow, I didn't know this became an ongoing thing

A good chunk of open&actionable issues have been addressed by WSL2. We didn't create a make-work project out of finding and marking them all fixed-in-wsl2, but if someone pipes up with a confirmation I'll usually tag-em if I see the post.

[EricGrahamMacEachern]

Thanks.

[EricGrahamMacEachern]

Thanks.