[bug#43857] Supporting chroot builds on GNU/Hurd

[Jan Nieuwenhuizen <janneke@gnu.org>]

Ludovic Courtès writes:

Hi!

> 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.).

Yay!  I finally got round to trying this, and I can confirm that it
also "almost works" for me.

[..]

> 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:

Yes, get something very similar.

> 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.

I also tried building util-linux and comparing it with the non-chrooted
build:

--8<---------------cut here---------------start------------->8---
-checking whether make sets $(MAKE)... yes
+checking whether make sets $(MAKE)... no

-                : mountpoint                  ... FAILED (libmount/utils-mountpoint)
+                : mountpoint                  ... SKIPPED (no /proc)

-  3 tests of 204 FAILED
+  2 tests of 204 FAILED
--8<---------------cut here---------------end--------------->8---

Not sure about the configure change, probably it uses /proc to determine
that?

Still failing:
--8<---------------cut here---------------start------------->8---
        fdisk: invalid input tests            ... FAILED (fdisk/oddinput)
         ipcs: headers                        ... FAILED (ipcs/headers)
--8<---------------cut here---------------end--------------->8---

so, this is already better.

> 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/*.

Yes, certainly maybe ;)

[..]

> Thoughts?

What about doing it in small steps, starting with the patch you suggest
here and see how much it "hurts" to go towards more secure/more Hurd'y
chrooted builds?

> From 1887d0dee0031df0de117b3a6339495504b4b489 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
> Date: Tue, 6 Oct 2020 23:53:24 +0200
> Subject: [PATCH] DRAFT daemon: Support chroot builds on GNU/Hurd.

So...apart from

> This has yet to be debugged.  :-)

otherwise, LGTM!

Thanks a lot for looking into this!

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com