Anyone made Goa work in NixOS? The problem I am having is that my fhs env seems to get broken by the goa tool. I tried to disable the sandbox system from goa through export DISABLE_SANDBOX=1 and by adding set disable_sandbox 1 to goa/share/goa/goarc, but does not seem to fix the error.
$ goa --version
bwrap: execvp git: No such file or directory
!!! Bumpy road ahead !!!
You seem to run a system with an unmerged /usr. This likely
affects the sandboxing mechanism. Please be aware that
you are leaving the beaten track.
child process exited abnormally
while executing
“exec -ignorestderr {}[goa_git_cmd [list] {}$args]”
(procedure “goa_git” line 2)
invoked from within
“goa_git rev-parse --abbrev-ref HEAD”
(procedure “current_goa_branch” line 3)
invoked from within
“current_goa_branch”
(file “/usr/local/goa/share/goa/lib/command_line.tcl” line 29)
invoked from within
“source [file join $tool_dir lib command_line.tcl]”
(file “/usr/bin/goa” line 49)
$ which git
/usr/bin/git
The error message is a bit misleading here. The sandboxing tool used by goa (i.e. gaol) expects /bin to be a symlink to /usr/bin. I assume this is not the case on NixOS. For goa --version, disabling the sandboxing mechanism is currently ineffective. This is not intended and should be fixed. Do you mind creating an issue for this on genodelabs/goa: Tool for streamlining the development of Genode applications - Codeberg.org?
Despite this, goa should still work on your system if all binaries are in either of /usr/bin, /usr/sbin, /usr/local/bin or /usr/local/sbin. Let’s figure out why this is not the case…
Can you please give the following command a try:
goa$> ./share/goa/gaol --system-usr --verbose which git
I have created the issue #186 - goa on Guix/Nix - genodelabs/goa - Codeberg.org.
I am currently in the process of getting goa to work on GNU Guix and when running goa --version via guix shell I get the following error:
tickzip@guix ~> goa --version
bwrap: execvp git: No such file or directory
!!! Bumpy road ahead !!!
You seem to run a system with an unmerged /usr. This likely
affects the sandboxing mechanism. Please be aware that
you are leaving the beaten track.
child process exited abnormally
while executing
"exec -ignorestderr {*}[goa_git_cmd [list] {*}$args]"
(procedure "goa_git" line 2)
invoked from within
"goa_git rev-parse --abbrev-ref HEAD"
(procedure "current_goa_branch" line 3)
invoked from within
"current_goa_branch"
(file "/gnu/store/if70y5lhxxr9gf4cfnf57mnbirpq9ch8-goa-25.10/share/goa/lib/command_line.tcl" line 29)
invoked from within
"source [file join $tool_dir lib command_line.tcl]"
(file "/gnu/store/z1m6vk2zvm9bp4j8c5clfx5kif74x7c9-profile/bin/goa" line 49)
Unfortunately, when running the same command in a FHS container guix shell --container --emulate-fhs, I receive a different error
tickzip@guix ~ [env]$ goa --version
bwrap: execvp git: Too many levels of symbolic links
!!! Bumpy road ahead !!!
You seem to run a system with an unmerged /usr. This likely
affects the sandboxing mechanism. Please be aware that
you are leaving the beaten track.
child process exited abnormally
while executing
"exec -ignorestderr {*}[goa_git_cmd [list] {*}$args]"
(procedure "goa_git" line 2)
invoked from within
"goa_git rev-parse --abbrev-ref HEAD"
(procedure "current_goa_branch" line 3)
invoked from within
"current_goa_branch"
(file "/gnu/store/g8agbpj8w317lyv2dnf1hhfrprxpk4ca-profile/share/goa/lib/command_line.tcl" line 29)
invoked from within
"source [file join $tool_dir lib command_line.tcl]"
(file "/bin/goa" line 49)
I assume this is because the FHS paths e.g. /bin/git are symlinked first to the profile (/gnu/store/...-profile/bin/git) for the container which are then symlinked to their canonical location (/gnu/store/...-git-2.54.0/bin/git).
@jschlatow here is the result of your command
tickzip@guix ~ [1]> /gnu/store/z1m6vk2zvm9bp4j8c5clfx5kif74x7c9-profile/share/goa/gaol --system-usr --verbose $(which git)
!!! Bumpy road ahead !!!
You seem to run a system with an unmerged /usr. This likely
affects the sandboxing mechanism. Please be aware that
you are leaving the beaten track.
Executing: bwrap --dir /var --dir /tmp --symlink ../tmp /var/tmp --dev /dev --proc /proc --unshare-all --new-session --clearenv --die-with-parent --setenv DISPLAY :0.0 --setenv HOME /home/tickzip --dir /run/user/1000 --setenv XDG_RUNTIME_DIR /run/user/1000 --ro-bind /usr /usr --symlink usr/lib64 /lib64 --symlink usr/bin /bin --symlink usr/sbin /sbin --symlink usr/lib /lib --setenv PATH /usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin /gnu/store/z1m6vk2zvm9bp4j8c5clfx5kif74x7c9-profile/bin/git
bwrap: execvp /gnu/store/z1m6vk2zvm9bp4j8c5clfx5kif74x7c9-profile/bin/git: No such file or directory
tickzip@guix ~ [1]> /gnu/store/z1m6vk2zvm9bp4j8c5clfx5kif74x7c9-profile/bin/git --version
git version 2.54.0
Note that I am using my own guix-packaged version of goa. This is partly because some of the source file shebangs have to be changed to their guix equivalents (/usr/bin/make to /gnu/store/...make-4.4.1/bin/make).
(define-public goa
(package
(name "goa")
(version "26.04")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://codeberg.org/genodelabs/goa")
(commit version)))
(file-name (git-file-name name version))
(sha256 (base32 "1fixd28prmjpb0f4p8f4qmadljjprdikxb76401bpi0m18iyp20a"))))
(build-system copy-build-system)
(arguments
(list
#:install-plan
#~'(("bin" "bin")
("share" "share"))))
(native-inputs
(list expect tcl))
(home-page "https://genode.org")
(synopsis "TODO")
(description "TODO")
(license license:agpl3)))
1 Like
The problem appears to be related to bwrap and the tcl config not being respected, i tried your patch on codeberg, but didn’t work. I did a hack to make it pass the error by editing goa/share/goa/gaol by setting no_bwrap 1 as default setting, and on line 62 i added a / in front of usr/bin, so it now looks like this:
if {[file type /bin] != “link” || [file link /bin] != “/usr/bin”} {
The line 62 fix from usr/bin to /usr/bin fixes the “!!! Bumpy road ahead !!!” problem as nixshell when using pkgs.buildFHSEnv does in fact link /bin to /usr/bin. I am more surprised it doesn’t return the same error on different platforms.
If someone else wants to have a nixshell environment to use goa and build Genode i can share my cursed shell.nix here. It does assume your git clone of goa and have a folder called genode-tools is in the same folder as shell.nix. I kinda just hacked at it till it compiled lol. It compiles the tools from source as well last i checked.
# shell.nix
{ pkgs ? import <nixpkgs> {} }:
(pkgs.buildFHSEnv {
name = "Genode-env";
targetPkgs = pkgs: with pkgs; [
git
file
elfutils
elfutils.dev
gnumake
flex
bison
gnum4
pkg-config
zlib
gperf
e2tools
gptfdisk
ncurses5
ncurses5.dev
# Fix for GDB looking for ncursesw/ncurses.h
(runCommand "ncursesw-compat-headers" { } ''
mkdir -p $out/include/ncursesw
# Symlink all headers from ncurses.dev into the ncursesw subdirectory
for f in ${ncurses.dev}/include/*.h; do
ln -s "$f" $out/include/ncursesw/
done
# Also symlink the ncurses subdirectory if it exists (for internal includes)
if [ -d ${ncurses.dev}/include/ncurses ]; then
ln -s ${ncurses.dev}/include/ncurses $out/include/ncursesw/
fi
'')
expat
expat.dev
gnat
gmp
gmp.dev
gcc13
autoconf269
autogen
automake
wget
python3
gnupg
stdenv.cc.cc.lib
glibc.dev
linuxHeaders
rpcsvc-proto
expect
SDL2.dev
tcl
bc
qemu
libisoburn
libxml2
mawk
nawk
bubblewrap
bash-completion
];
extraBuildCommands = ''
mkdir -p $out/usr/local/genode
mkdir -p $out/usr/local/goa
mkdir -p $out/usr/share/bash-completion/completions
ln -s /usr/local/goa/share/bash-completion/goa \
$out/usr/share/bash-completion/completions/goa
ln -s /usr/local/goa/bin/goa $out/usr/bin/goa
'';
runScript = "bash";
extraBwrapArgs = [
"--bind" (toString ./genode-tools) "/usr/local/genode"
"--bind" (toString ./goa) "/usr/local/goa"
];
}).env
Other platforms (those that I’ve seen so far) use a relative symlink to usr/bin. Good to know that there are exceptions.
1 Like
Unfortunately, my fix was incomplete. I just pushed a fixup.
1 Like
Can confirm both fixes works now on NixOS. Thank you.
Guix is even more of an anomaly here since /usr/bin is a symlink pointing to /bin, which explains why I got
since there were circular references from gaol symlinking usr/bin to /bin and also binding /usr to /usr.