(address . guix-patches@gnu.org)
87sgapsnqz.fsf@gnu.org
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:
Toggle snippet (18 lines)
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
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’.