From: Marco van Hulten <marco@hulten.org>
To: help-guix@gnu.org
Subject: Re: protect generations
Date: Sun, 12 Jan 2020 15:57:22 +0100 [thread overview]
Message-ID: <20200112155722.00f6010a@jasniac.instanton> (raw)
In-Reply-To: <CAJ3okZ30WJUQxtD7qZDoCKuMKo7-nrA+q0zxQ03bCY48g7LxvQ@mail.gmail.com>
Marius Bakke wrote:
> There are AFAIK two ways in which 'guix gc' can delete "live" profiles:
>
> 1. you used the '-d' option, which deletes old profile generations,
> optionally filtering on age
This was the case. I did
guix gc --delete-generations=1m
which deleted the last month of generations. The profile that I wanted
to retain was a bit older than one month.
Apropos, in the documentation of 'guix gc' I read:
> -d [duration]
>
> Before starting the garbage collection process, delete all the
> generations older than duration, for all the user profiles; when
> run as root, this applies to all the profiles of all the users.
I suppose the first mention of "all the user profiles" should not be
there, as a non-priviledged user should not be able to remove
generations from others' user profiles. (This does, indeed, appear not
to be the case — the accidental removal of the generation in question
was one of the user who ran the gc command; other users' old
generation stayed in tact.) Instead it should read
> -d [duration]
>
> Before starting the garbage collection process, delete all the
> generations older than duration from the current user's profile; when
> run as root, this applies to all the profiles of all the users.
Je 7 jan 13:11 skribis zimoun:
> On Sun, 5 Jan 2020 at 22:42, Marco van Hulten <marco@hulten.org> wrote:
>
> > One of the great features of Guix is that one can roll back his
> > profile. But I did a garbage collection (gc) that was too aggressive
> > such that a relevant old profile disappeared. I presume this is gone
> > forever.
>
> From my understanding, yes gone but not necessary forever.
>
> How did you instantiate the profile? Using a manifest file? Did the
> profile use only one Guix commit or several?
> How aggressive it was? What did you run?
I have never used manifest files but usually use the imperative method
of 'guix package -i ... -r ... -u' or sometimes I change to another
"live" profile.
> > Is it possible to lock certain generations (of certain users) such that
> > 'guix gc' would not touch it?
>
> Interesting whislist.
In retrospect, a realisation of this wish would probably introduce
unnecessary complexity of 'guix gc'. So nevermind. :-)
> Currently, the easiest way to protect the state of a profile is to
> write down a manifest file, IMHO.
> If this manifest file track the Guix commit and the targeted packages,
> then you can re-instantiate this very profile whereever and whenever
> you want to.
I see how I can declare a specific manifest be used (by giving the
manifest file). How do I create (or where do I find) the manifest file
from the currently running generations?
Can you give a minor clarification on the terms 'generation' and
'profile'? I understand that the a generation is an abstract term
defining a profile. Generations correspond with
/var/guix/profiles/per-user/*/guix-profile*
, which is actually a subset, above referred to as "live" profiles. The
running profile is the realpath(1) of ~/.guix-profile/.
Are 'generations' and 'profiles' not basically the same thing?
Instead of trying to restore the removed generation/profile, I try to
fix the issue that I'm experiencing in newer generations. I might ask
about this in a new thread if I cannot figure it out.
—Marco
next prev parent reply other threads:[~2020-01-12 14:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-05 21:42 protect generations Marco van Hulten
2020-01-07 12:11 ` zimoun
2020-01-12 14:57 ` Marco van Hulten [this message]
2020-01-14 16:38 ` zimoun
2020-01-15 8:38 ` Efraim Flashner
2020-01-15 10:54 ` zimoun
2020-01-11 23:50 ` Marius Bakke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200112155722.00f6010a@jasniac.instanton \
--to=marco@hulten.org \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).