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