build ocaml-base-compiler fails on versions 4.02-4.08 (`opam switch create . 4.06.1`)

[mprevot]

I'm using opam 2.0.0~rc2 and for opam switch create . 4.06.1 I got:

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
∗ installed base-bigarray.base
∗ installed base-threads.base
∗ installed base-unix.base
[ERROR] The compilation of ocaml-base-compiler failed at "/home/user/.opam/opam-init/hooks/sandbox.sh build ./configure -prefix /mnt/i/LangCompil/td1/_opam -with-debug-runtime".

#=== ERROR while compiling ocaml-base-compiler.4.06.1 =========================#
# context     2.0.0~rc2 | linux/x86_64 |  | https://opam.ocaml.org/2.0#b36f28db
# path        /mnt/i/LangCompil/td1/_opam/.opam-switch/build/ocaml-base-compiler.4.06.1
# command     ~/.opam/opam-init/hooks/sandbox.sh build ./configure -prefix /mnt/i/LangCompil/td1/_opam -with-debug-runtime
# exit-code   1
# env-file    ~/.opam/log/ocaml-base-compiler-3314-d2d111.env
# output-file ~/.opam/log/ocaml-base-compiler-3314-d2d111.out
### output ###
# Creating new namespace failed: Invalid argument

How to resolve this ?

[rjbou]

Can you run on verbose mode (-vv) and post the log?

[mprevot]

Can you please confirm if it's opam switch create . 4.06.1 -vv and tell me where I can find the log ?

[rjbou]

Yes!
Given your first post, it is this command that fails (creation of a ocaml-4.06.1 switch in the current directory). Option -vv (the number of v increase the log level) enable verbose mode and print log on stdout. It will give more information/precision about the failing step.

[mprevot]

I didn't got more details unfortunately. But I have this new detail:
bwrap: Creating new namespace failed: Invalid argument

<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
┌─ The following actions were aborted
│ ∗ install ocaml 4.06.1
└─
┌─ The following actions failed
│ λ build ocaml-base-compiler 4.06.1
└─
┌─ The following changes have been performed (the rest was aborted)
│ ∗ install base-bigarray base
│ ∗ install base-threads base
│ ∗ install base-unix base
└─

(I'm using different distributions WSL: ubuntu 16.04, ubuntu 18.05 and kali)

[rjbou]

bwrap, the sandboxing tool, seems to be unable to create a namespace. You can find all bwrap argument in ~/.opam/opam-init/sandbox.sh.
Can you try this command, simplified version of opam bwrap command which should work and launch pwd:

bwrap \
--unshare-net \
--new-session \
--ro-bind /bin /bin \
--ro-bind /lib /lib \
--ro-bind /lib32 /lib32 \
--ro-bind /lib64 /lib64 \
--ro-bind /home /home \
pwd

[mprevot]

The path was ~/.opam/opam-init/hooks/sandbox.sh.
unfortunately, it failed too :

bwrap: Creating new namespace failed: Invalid argument

it failed too on the github example:

bwrap --ro-bind /usr /usr --symlink usr/lib64 /lib64 --proc /proc --dev /dev --unshare-pid bash
bwrap: Failed to make / slave: Invalid argument

Is it calling the kernel in some way ? I suspect because WSL has an incomplete kernel interface, it fails there.

ls /
bin boot dev etc home init lib lib64 media mnt opt proc root run sbin snap srv sys tmp usr var

[rjbou]

Indeed, bwrap is not supported by WSL (cf. this issue).
To be able to use opam in your case, you can disable sandboxing (use with caution) using the --disable-sandboxing option for a fresh opam initialisation or via an opamrc. For an initialised opam, you can't use this option, but change the configuration directly in the config file by removing / empty wrap-*-command fields.
See this faq entry for further information.
And I repeat the warning here: "Use [sanbdoxing disable option] wisely, broken Makefiles that run rm -rf / do happen."

[mprevot]

Thanks for the details, the solution and the warning. In my case, I built a safely an opam local repo from a VM and copied it to WSL.

[bluddy]

Looks like the issue has been fixed in an insider build, which means we'll eventually get it.

[dra27]

This issue hasn't been fixed in WSL - for the foreseeable, sandboxing will need to remain disabled.

[mprevot]

If it's not fixed in insider build, can a developer explain what would be needed, so we create a feature request to MSFT ?

[rjbou]

It depends of the error cause. If it is a mount propagation flag error, it should have been fixed.
As told in a previous comment, bubblewrap contains some stuff that are not yet supported:

Yes, but bubblewrap.c is a who's-who of stuff we don't have.

A bubblewrap developer would be more relevant for the feature request. Maybe opening an issue on their tracker?

[mprevot]

Done: bubblewrap#272