'guix system init' should store derivation outputs on target store

(As reported by Adam Pribyl <pribyl@lowlevel.cz>.)

As of v0.6-598-g66c2703, ‘guix system init’ first builds stuff in the

current store, which is typically a RAM disk when booting from the USB

stick, and then copies the result to the target.

The problem is that RAM is typically finite.

Ludo’.

There are two ways I can think of to fix this:

1. Have ‘guix system init’ launch a new guix-daemon chrooted under the

target directory, and then use it to perform all the builds.

2. Use file system magic, presumably involving a COW unionfs so that

writes to the in-RAM /gnu/store go to the user’s disk.

The first option seemed easy but has several problems. First there are

several places in the (guix ...) modules that memorize derivation, which

causes breakage when ‘guix system’ switches to the new store because the

corresponding .drv files are invalid there. That can be worked around.

But then, when talking to the chrooted store, ‘guix system’, in

‘derivation-hash’, tries to read .drv files that may be missing from the

initial store. (Current patch attached, for posterity.)

So I’m now looking at option #2.

Ludo’.

Commit 83a17b6 solves this by adding a ‘cow-store’ service that makes

/gnu/store copy-on-write, with the user’s installation disk as the

backing store.

This requires users to explicitly type:

deco start cow-store /mnt

before running ‘guix system init’, but that seems like an acceptable

trade-off.

Ludo’.