-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep last "known good" profile when running nix-collect-garbage
#5818
Comments
One option could make making a separate profile called “known-good” and
updating that profile when you know a generation is good.
On December 22, 2021, GitHub ***@***.***> wrote:
Is your feature request related to a problem? Please describe.
Running with the --delete-old flag makes any rollback impossible,
which is risky. And picking a reasonable --delete-older-than period to
keep at least N profiles while reducing disk usage as much as possible
means having to look through the list of generations to work out the
amount of time since the last N builds and running with that plus a
bit of a margin. This is cumbersome.
Describe the solution you'd like
The ideal solution would keep only the last known good profile plus
the current profile. That way a working fallback is always available,
and I can still attempt booting into the new (untested) profile, while
ensuring minimal disk use.
This might be complicated to achieve, especially since "known good" is
hard to pin down even for system profiles. For example, a system might
boot, and might even start an X server, only to consistently crash a
few seconds later due to a video driver bug (this happened to me
recently).
A good enough solution might be a flag to keep the last N profiles.
How this interacts with --delete-old and --delete-older-than is
probably not that important.
—
Reply to this email directly, view it on GitHub
<#5818>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AAASXLGD333E5P72ZFVR4ZDUSGQ5PANCNFSM5KSGQB6Q>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-
email&mt=8&pt=524675> or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-
email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Workaround: if you go to such lengths, I'd rather just "manually" delete the symlinks according to your wishes. (And it's quite easy to script one-liners for last-N, etc.) |
I marked this as stale due to inactivity. → More info |
Another workaround for this particular solution: You can garbage collect all but the last N system profiles by running: A simple maintenance script might look something like: nix-env --profile /nix/var/nix/profiles/system --delete-generations +5
nix-collect-garbage
nix-store --optimise Footnotes |
Is your feature request related to a problem? Please describe.
Running with the
--delete-old
flag makes any rollback impossible, which is risky. And picking a reasonable--delete-older-than
period to keep at least N profiles while reducing disk usage as much as possible means having to look through the list of generations to work out the amount of time since the last N builds and running with that plus a bit of a margin. This is cumbersome.Describe the solution you'd like
The ideal solution would keep only the last known good profile plus the current profile. That way a working fallback is always available, and I can still attempt booting into the new (untested) profile, while ensuring minimal disk use.
This might be complicated to achieve, especially since "known good" is hard to pin down even for system profiles. For example, a system might boot, and might even start an X server, only to consistently crash a few seconds later due to a video driver bug (this happened to me recently).
A good enough solution might be a flag to keep the last N profiles.
How this interacts with
--delete-old
and--delete-older-than
is probably not that important.The text was updated successfully, but these errors were encountered: