./pre-inst-env guix build dangerous inside an environment?

./pre-inst-env guix build dangerous inside an environment?

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

While developing my first package definition to be contributed to GNU
Guix, I followed 14.1 („Building from Git”) and 14.2 („Running
Guix Before It Is Installed”) of the manual.

14.1 suggests using a Guix environment via `guix environment guix`. I
thought it would be even better to do `guix environment --pure guix`,
and thus obtain some higher level of isolation.

I decided to continue with the environment in 14.2. Issuing

   sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild

resulted in some error related to UID/GID. Outside the environment, it
worked, though. Inside the environment, I issued the next line from the
manual:

   ./pre-inst-env guix build hello

A massive build of various packages, including gcc, linux-libre…,
began. After a while, “sed not found” and other “not founds”
started to appear in other terminal windows (tmux panels in my case),
unrelated to the described process, and the system got impossible to
work with. After a reset, instead of the OS, I got landed in the Guile
interpreter (in kind of a debug mode, as far as I could say). It looks
like the build wiped out the store, and tomorrow’s going to be a
re-installation and reconfiguration day.

Could somebody, please, help me understand what kind of mistake I made
and what actually happened? Don’t you think it would be desirable
to mark with `[env]` the commands that should be issued inside an
environment in the manual? I find 14.2 rather confusing in this regard.
Perhaps, it would be also worthwhile to include a warning in order to
spare other newcomers a similar experience.

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: ./pre-inst-env guix build dangerous inside an environment?

[Ricardo Wurmus]

Hi Wiktor,

> While developing my first package definition to be contributed to GNU
> Guix, I followed 14.1 („Building from Git”) and 14.2 („Running
> Guix Before It Is Installed”) of the manual.
>
> 14.1 suggests using a Guix environment via `guix environment guix`. I
> thought it would be even better to do `guix environment --pure guix`,
> and thus obtain some higher level of isolation.

How did you configure Guix?  This sounds like perhaps you ran
“./configure” without “--localstatedir=/var”, so that Guix would be
using a different location for its database and thus consider existing
stuff in /gnu to be invalid.

This is not a problem with using an environment.  The problem is with
using a Guix that is misconfigured so that it considers /gnu to be
“polluted” and cleans it up according to the fresh database that is
found at the default localstatedir (which is not /var).

--
Ricardo

Re: ./pre-inst-env guix build dangerous inside an environment?

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Tue, Sep 10, 2019 at 04:37:03PM +0200, Ricardo Wurmus wrote:

> This sounds like perhaps you ran “./configure” without
> “--localstatedir=/var”, so that Guix would be using a different
> location for its database and thus consider existing stuff in /gnu to
> be invalid.

Thank you for your prompt reply, Ricardo.

Yeah, that’s precisely what happened. I missed (or just lazily,
hastily ignored) the “Make sure to pass --localstatedir=directory”
sentence. I’m glad there exists at least an explanation for that
disaster.

Don’t you think it would be reasonable to follow that sentence with
something like: *Otherwise, you risk that the default store in `/gnu`
becomes damaged*?

> This is not a problem with using an environment.

Still, it seems to me unclear from the manual (at least as far as
14.2 is concerned) whether anything is gained by doing test builds in
an environment, and thus whether this is the recommended way, and if
so—for which steps.

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: ./pre-inst-env guix build dangerous inside an environment?

[Ricardo Wurmus]

Hi Wiktor,

> On Tue, Sep 10, 2019 at 04:37:03PM +0200, Ricardo Wurmus wrote:
>
>> This sounds like perhaps you ran “./configure” without
>> “--localstatedir=/var”, so that Guix would be using a different
>> location for its database and thus consider existing stuff in /gnu to
>> be invalid.
>
> Thank you for your prompt reply, Ricardo.
>
> Yeah, that’s precisely what happened. I missed (or just lazily,
> hastily ignored) the “Make sure to pass --localstatedir=directory”
> sentence. I’m glad there exists at least an explanation for that
> disaster.
>
> Don’t you think it would be reasonable to follow that sentence with
> something like: *Otherwise, you risk that the default store in `/gnu`
> becomes damaged*?

I think this failure mode is pretty terrible and I’m really sorry that
you encountered it.  I think it’s not a good idea for Guix to delete
stuff from /gnu/store just because the database says that the
directories are invalid.

I also suffered from this problem in the big production environment at
the institute where I work — luckily Guix failed to delete things early
due to a permission problem, so I didn’t lose all of /gnu.

I wonder if the daemon should just abort with an error when it
encounters an unknown directory.  The problem with that is that
sometimes directories are left behind when the daemon was forcibly
killed, and we want those to be cleaned up automatically.

@Ludo, what do you think about this?

>> This is not a problem with using an environment.
>
> Still, it seems to me unclear from the manual (at least as far as
> 14.2 is concerned) whether anything is gained by doing test builds in
> an environment, and thus whether this is the recommended way, and if
> so—for which steps.

Using a git checkout and an environment is the recommended way to
contribute to Guix, because you’ll have access to the most current
version of Guix.  Building with “./pre-inst-env guix build” lets Guix
use the (potentially modified) source checkout, so you have access to
work-in-progress package definitions before they are added to Guix
proper.  Once the build is successful you can submit a patch and the
package would eventually become part of Guix.

Without a git checkout (and an environment to provide the required
dependencies to work with it) you’d have a hard time contributing to
Guix.

--
Ricardo

Re: ./pre-inst-env guix build dangerous inside an environment?

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Wed, Sep 11, 2019 at 09:40:45PM +0200, Ricardo Wurmus wrote:

> I think this failure mode is pretty terrible and I’m really sorry
> that you encountered it.

At least I learned something about Guix workings. The system is back.
This time, I completed 14.2 without a disaster.

> I wonder if the daemon should just abort with an error when it
> encounters an unknown directory. The problem with that is that
> sometimes directories are left behind when the daemon was forcibly
> killed, and we want those to be cleaned up automatically.

rm -i
cp -i
mv -i

from the shell world come to my mind. Or some --dry-run mode.

> (and an environment to provide the required dependencies to work with
> it)

I guess I need to learn more about Guix environments.

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]