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

["Ludovic Courtès" <ludo@gnu.org>]

Hi Mathieu!

Mathieu Othacehe <othacehe@gnu.org> skribis:

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

Yeah, no big deal.

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

Yeah…  (I must say I really appreciate your commitment tackling hard
problems like this one, kudos!)

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

OK, makes sense!

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

It does seem complex indeed.

So perhaps we can settle on the solution you sent, but let’s see if we
can move complexity out of sight.  For example, if we can arrange to
have a ‘fork+exec-command/container’ procedure that can be passed the
PID of a namespace, such that the ‘start’ method of guix-daemon is just
a few more lines its current definition, I’ll be happy.

How does that sound?

Thank you!

Ludo’.