[bug#42849] [PATCH 3/3] installer: Run the installation inside a container.

[Mathieu Othacehe]

> Should ‘mount-cow-store’ also make an overlay for /var/guix/db?  That
> way, changes to that directory would go to /mnt/var/guix/db and the
> original database would remain unchanged.

I took the lazy path because it's just one file that keeps reasonably
small. Adding an extra overlay for /var/guix/db would make
sense here.

>
> Hmm, that seems quite complex, and it’s not great that we have to tweak
> guix-daemon-service “just” for this.

Yes I can't say I'm satisfied with all of this but I'm trying different
angles for this problem since months, with no proper outcome.

> Is there a way we can identify processes that have open overlay files,
> so we could terminate them?

That's the current approach but it breaks very ofter because kmscon,
udev or any other processes that can't be killed, opens an overlay file.
I'd really like to avoid relying on this kind of solution.

> Alternately, something that might simplify the code would be to always
> run guix-daemon in a separate mount namespace.  We could add a
> ‘fork+exec-command/container’ procedure in (gnu build shepherd) to help
> with that.
>
> That way, all we’d need to do is to run ‘guix system init’ in that same
> mount namespace, which can be achieved using ‘container-excursion’.

Yes I tried that at first but there's a catch. While running guix-daemon
in it's own mount namespace, it won't 'see' the mounted file-systems
such as /mnt.

So that would mean that we would have to do spawn a containerized
process that would:

* Join guix-daemon mnt namespace
* Call "with-mounted-partitions"
* Mount the cow-store
* Run 'guix system init'

In this is end it still seem overly complex, but I can give it another
try. WDYT?

Thanks a lot for reviewing this!

Mathieu