Hello!

The patch below is an attempt at supporting “chroot builds” on GNU/Hurd;
it’s “almost working”.  The main feature we need is firmlinks (or “bind
mounts”) and commenting out Linux-specific things (private bind mounts,
‘pivot_root’, etc.).

The patch introduces a ‘firmlink’ function that creates a bind mount on
GNU/Linux and otherwise spawns the /hurd/firmlink translator.  It also
adjusts ‘deletePath’ to remove any active translators from files it’s
about to delete, the goal being to terminate those firmlink translators.
(Apparently that code isn’t reached yet though.)

The set of /dev nodes firmlinked into the chroot is reduced compared to
GNU/Linux; I added /servers, meaning that /servers is firmlinked as is,
which is not ideal (see below).

With this patch, I can run “guix build hello --check” in a chroot…  but
it eventually hangs somewhere in ‘DerivationGoal::buildDone’ (I presume)
once the build has completed.  It leaves behind it all its firmlink
processes:

--8<---------------cut here---------------start------------->8---
root@childhurd ~# ps --width=200 aux|grep firmlink
root     16426 120.0 0.0  147M  616K p1 RNm  11:38PM  0:00.00 grep --color=auto firmlink
root     11191  0.0  0.0  147M  888K  - S<o  11:27PM  0:00.00 /hurd/firmlink /dev/full
root     11192  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.01 /hurd/firmlink /dev/null
root     11193  0.0  0.0  147M  888K  - S<o  11:27PM  0:00.00 /hurd/firmlink /dev/random
root     11194  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.00 /hurd/firmlink /dev/urandom
root     11195  0.0  0.0  147M  888K  - S<o  11:27PM  0:00.00 /hurd/firmlink /dev/zero
root     11196  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.02 /hurd/firmlink /gnu/store/1brrgqhgjni8g8dbp97s8c7d7nq0p9a0-libgc-8.0.4
root     11197  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.05 /hurd/firmlink /gnu/store/1gmsfg4cfmj3l54s3nkn3lyas3nnzjgs-hurd-core-headers-0.9-1.91a5167
root     11198  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.00 /hurd/firmlink /gnu/store/5ndcmqx0pzksq5c4mznbv20xhfnk3p97-zlib-1.2.11
root     11199  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.02 /hurd/firmlink /gnu/store/631ixr5flpk66ziigbmkxwafz8skpyzs-findutils-4.7.0
root     11200  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.59 /hurd/firmlink /gnu/store/6zfpncmmz1aqpsg1ba7zjna8qb4nmwdx-file-5.38
[...]
root     11233  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.58 /hurd/firmlink /gnu/store/zjlh3sljylr3y1cavxp2z7g37g922mbb-gcc-7.5.0
root     11234  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.02 /hurd/firmlink /servers
root     11235  0.0  0.0  147M  936K  - S<o  11:27PM  0:00.07 /hurd/firmlink /tmp/guix-build-hello-2.10.drv-6
--8<---------------cut here---------------end--------------->8---

This has yet to be debugged.  :-)

Apart from that, this raises the question of what to put in the build
environment.  As written in the blog post about childhurds that should
go out tomorrow, on GNU/Linux, we do not include any piece of userland
software in the environment.  But here, we’d be doing just that: running
Hurd translators that are not specified as derivation inputs.  It’s OK
for /dev/null, but maybe questionable for /servers/socket/*.

Regarding /servers, we’ll probably want to spawn separate servers (a
separate /servers/proc would give up a new “PID namespace”.)  Should
that be done magically by the daemon, or should we leave it up to build
processes, so that build processes really specify all the user-land
software they depend on?  We could imagine a new phase in
‘gnu-build-system’, on GNU/Hurd, that would start by setting up a bunch
of translators.  Food for thought…  As a first step, we can firmlink it
from the host, with an eye towards “doing it right”.

I felt a need to hack on this as I was investigating an util-linux test
failure in a ‘--disable-chroot’ setup: the test would find /proc and
would later fail for some reason.  Had /proc been missing from the build
environment (as is the case with this patch), the test would have been
skipped (it explicitly handles that case).  I think we’d rather not
fiddle too much with test suites until we have defined what’s available
in the default build environment.

Thoughts?

For the record, I’ve been testing this by:

  1. Adding ‘hurd’ as an input to the ‘guix’ package.

  2. Cross-building the daemon using code from my branch:

    ~/src/guix/pre-inst-env guix build --with-git-url=guix-daemon=$PWD --with-branch=guix-daemon=wip-hurd-chroot --target=i586-pc-gnu  -e '(@ (gnu packages package-management) guix-daemon)'

  3. Sending it over to the childhurd:

     guix copy --to=localhost:10022 /gnu/store/…

  4. Running it in the childhurd with:

     GUIX=/run/current-system/profile/bin/guix /gnu/store/…-guix-daemon-git.wip-hurd-chroot/bin/guix-daemon --build-users-group=guixbuild --disable-deduplication

I guess I should probably go ahead and do everything natively in the
childhurd, but I thought I’d share my weird workflow in case that gives
me a chance to participate in some weirdness contest.

Ludo’.