* protect generations
@ 2020-01-05 21:42 Marco van Hulten
2020-01-07 12:11 ` zimoun
2020-01-11 23:50 ` Marius Bakke
0 siblings, 2 replies; 7+ messages in thread
From: Marco van Hulten @ 2020-01-05 21:42 UTC (permalink / raw)
To: help-guix
Hello—
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.
Is it possible to lock certain generations (of certain users) such that
'guix gc' would not touch it?
—Marco
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: protect generations
2020-01-05 21:42 protect generations Marco van Hulten
@ 2020-01-07 12:11 ` zimoun
2020-01-12 14:57 ` Marco van Hulten
2020-01-11 23:50 ` Marius Bakke
1 sibling, 1 reply; 7+ messages in thread
From: zimoun @ 2020-01-07 12:11 UTC (permalink / raw)
To: Marco van Hulten; +Cc: help-guix
Hi,
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?
> Is it possible to lock certain generations (of certain users) such that
> 'guix gc' would not touch it?
Interesting whislist.
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.
Hope that helps.
All the best,
simon
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: protect generations
2020-01-05 21:42 protect generations Marco van Hulten
2020-01-07 12:11 ` zimoun
@ 2020-01-11 23:50 ` Marius Bakke
1 sibling, 0 replies; 7+ messages in thread
From: Marius Bakke @ 2020-01-11 23:50 UTC (permalink / raw)
To: Marco van Hulten, help-guix
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Marco van Hulten <marco@hulten.org> writes:
> Hello—
>
> 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.
>
> Is it possible to lock certain generations (of certain users) such that
> 'guix gc' would not touch it?
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
2. the profile was inaccessible/invisible to gc (e.g. on a mounted drive
that was unavailable)
Do either of these scenarios ring a bell?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: protect generations
2020-01-07 12:11 ` zimoun
@ 2020-01-12 14:57 ` Marco van Hulten
2020-01-14 16:38 ` zimoun
0 siblings, 1 reply; 7+ messages in thread
From: Marco van Hulten @ 2020-01-12 14:57 UTC (permalink / raw)
To: help-guix
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: protect generations
2020-01-12 14:57 ` Marco van Hulten
@ 2020-01-14 16:38 ` zimoun
2020-01-15 8:38 ` Efraim Flashner
0 siblings, 1 reply; 7+ messages in thread
From: zimoun @ 2020-01-14 16:38 UTC (permalink / raw)
To: Marco van Hulten; +Cc: help-guix
Hi,
On Sun, 12 Jan 2020 at 15:57, Marco van Hulten <marco@hulten.org> wrote:
> > 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.
You should be interested to read this entry:
http://guix.gnu.org/cookbook/en/guix-cookbook.html#Guix-Profiles-in-Practice
> > > 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. :-)
No, it appears to me interesting. :-)
For example, let consider this scenario:
guix package --install list of packages # (1)
guix package -i other ones -r some # (2)
guix package --upgrade # (3)
guix package -i again -r bye bye # (4)
guix package --roll-back # (5)
guix package -i kikoo # (6)
etc.
Now, the profile at the generation (6) is fine and you want to garbage
collect all the previous generations. But you know that the generation
(2) was ok. To my knowledge, it is not easy to GC the generations 1,
3, 4, 5 without collecting the 2.
Well, so we can imagine something like:
guix gc --lock=2
guix gc
and now if you roll-back from 6, you obtain the profile of the generation 2.
I am not sure to be clear. :-)
But it is an interesting whishlist.
> Are 'generations' and 'profiles' not basically the same thing?
You can try:
guix package --list-generations
You will see all the transactions for the default profile ~/.guix-profile.
Well, the profile is what lives in ~/.guix-profile. Each time you do a
transaction (install/remove/upgrade), you alter this directory and
this modification is a generation.
Using a Git analogy, the generations corresponds to the commits and
the profile corresponds to the files.
> 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.
Please. :-)
All the best,
simon
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: protect generations
2020-01-14 16:38 ` zimoun
@ 2020-01-15 8:38 ` Efraim Flashner
2020-01-15 10:54 ` zimoun
0 siblings, 1 reply; 7+ messages in thread
From: Efraim Flashner @ 2020-01-15 8:38 UTC (permalink / raw)
To: zimoun; +Cc: help-guix
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
>
> For example, let consider this scenario:
>
> guix package --install list of packages # (1)
> guix package -i other ones -r some # (2)
> guix package --upgrade # (3)
> guix package -i again -r bye bye # (4)
> guix package --roll-back # (5)
> guix package -i kikoo # (6)
> etc.
>
> Now, the profile at the generation (6) is fine and you want to garbage
> collect all the previous generations. But you know that the generation
> (2) was ok. To my knowledge, it is not easy to GC the generations 1,
> 3, 4, 5 without collecting the 2.
>
In this scenario you can run 'guix gc --delete-generations=1,3,4,5'
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: protect generations
2020-01-15 8:38 ` Efraim Flashner
@ 2020-01-15 10:54 ` zimoun
0 siblings, 0 replies; 7+ messages in thread
From: zimoun @ 2020-01-15 10:54 UTC (permalink / raw)
To: Efraim Flashner; +Cc: help-guix
Hi Efraim,
On Wed, 15 Jan 2020 at 09:39, Efraim Flashner <efraim@flashner.co.il> wrote:
> In this scenario you can run 'guix gc --delete-generations=1,3,4,5'
Cool!
It reminds me to add the '--no-<option>' to some wishlist. :-)
For example, see [1] about "guix lint". Something similar could be added here:
guix gc --no-delete-generations=2
would garbage collect everything except the generation 2.
WDYT?
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37224#34
All the best,
simon
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-01-15 10:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-05 21:42 protect generations Marco van Hulten
2020-01-07 12:11 ` zimoun
2020-01-12 14:57 ` Marco van Hulten
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
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.