GNU bug report logs - #64472
guix pull --roll-back breaks guix

Previous Next

Package: guix;

Reported by: Blake Shaw <blake <at> reproduciblemedia.com>

Date: Wed, 5 Jul 2023 10:22:02 UTC

Severity: normal

To reply to this bug, email your comments to 64472 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#64472; Package guix. (Wed, 05 Jul 2023 10:22:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Blake Shaw <blake <at> reproduciblemedia.com>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Wed, 05 Jul 2023 10:22:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Blake Shaw <blake <at> reproduciblemedia.com>
To: bug-guix <at> gnu.org
Subject: guix pull --roll-back breaks guix
Date: Wed, 05 Jul 2023 17:21:23 +0700
[Message part 1 (text/plain, inline)]
Hiya Guix,

I just encountered a surprising bug.

I've been trying to get the [redacted] proprietary GPU drivers to work on my system (but this isnt particular to the issue at hand), and I "guix installed" the [redacted-module] package in my .guix-profile, to see if that would help me with the failed

$ modprobe [redacted]

that I was experiencing.

It didn't, so I decided to do what we do best: roll-back. But I accidentally ran

$ guix pull --roll-back

instead of

$ guix package --roll-back

This mistake should be trivial, fixable by running

$ guix pull --switch-generation=N

Where N is the "FROM" field of the roll-back message that guix displays following a successfull roll back.

But to my surprise an anomaly appeared in the "TO" field of the roll-back message:

$ guix pull --roll-back
building path(s) `/gnu/store/2s7a7h...gj23-profile`
switched from generation 86 to 0

Huh? Zero? It should have switched to 85. Weird, but np, let's just direct it to 85.

$ guix pull --switch-generation=85
-bash: /home/my-profile/.config/guix/current/bin/guix

So now it can't find guix. Visiting .config/guix/current/ it is empty except an etc dir and a manifest. so I use guix from the run directory to get back on track:

$ exec /run/current-system/profile/bin/guix --switch-generation=85
guix pull error: cannot switch to generation '85'

$ exec /run/current-system/profile/bin/guix --switch-generation=86
switched from generation 0 to 86

And then $HOME/.config/guix/current is back to normal and everything works fine. So I assume this was due to yesterday's guix gc --delete-generations=1d

But like, should this happen? Should we ever be rolling back to an empty "0" generation that doesn't even contain guix, and thus creates a pickle for those who don't have prior knowledge of how to get out of it? Should we limit gc --delete-generations to always keep a previous generation at hand, perhaps unless forced by some other flag, so that [in particular, new] users don't break their systems in the middle of the day and then have something to solve that encumbers their plans & work?

Happy hacking!
Blake
[Message part 2 (text/html, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#64472; Package guix. (Sat, 25 Nov 2023 11:09:02 GMT) Full text and rfc822 format available.

Message #8 received at 64472 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Blake Shaw <blake <at> reproduciblemedia.com>
Cc: 64472 <at> debbugs.gnu.org
Subject: Re: bug#64472: guix pull --roll-back breaks guix
Date: Fri, 24 Nov 2023 11:17:32 +0100
Hi,

Indeed, the issue can be annoying.

--8<---------------cut here---------------start------------->8---
$ guix gc ---delete-generations=0d

$ guix pull --roll-back
fetching path `/gnu/store/…-module-import-compiled'...
Downloading https://ci.guix.gnu.org/nar/lzip/…-module-import-compiled...
 module-import-compiled  107KiB       1.4MiB/s 00:00 ▕██████████████████▏ 100.0%
fetching path `/gnu/store/…-libffi-3.4.4'...
Downloading https://ci.guix.gnu.org/nar/lzip/…-libffi-3.4.4...
 libffi-3.4.4  56KiB                  6.3MiB/s 00:00 ▕██████████████████▏ 100.0%
fetching path `/gnu/store/…-libgc-8.2.2'...
Downloading https://ci.guix.gnu.org/nar/zstd/…-libgc-8.2.2...
 libgc-8.2.2  228KiB                  2.3MiB/s 00:00 ▕██████████████████▏ 100.0%
fetching path `/gnu/store/…-libunistring-1.0'...
Downloading https://ci.guix.gnu.org/nar/zstd/…-libunistring-1.0...
 libunistring-1.0  661KiB             2.7MiB/s 00:00 ▕██████████████████▏ 100.0%
fetching path `/gnu/store/…-pkg-config-0.29.2'...
Downloading https://ci.guix.gnu.org/nar/zstd/…-pkg-config-0.29.2...
 pkg-config-0.29.2  209KiB            2.3MiB/s 00:00 ▕██████████████████▏ 100.0%
fetching path `/gnu/store/…-guile-3.0.9'...
Downloading https://ci.guix.gnu.org/nar/zstd/…-guile-3.0.9...
 guile-3.0.9  8.1MiB                  1.6MiB/s 00:05 ▕██████████████████▏ 100.0%

building path(s) `/gnu/store/zm6cs3grf3l78mz1swakvfddn6k66l7m-profile'
switched from generation 29 to 0
--8<---------------cut here---------------end--------------->8---

Aside the unexpected downloads, now Guix have disappeared…

        $ hash guix
        $ type -P guix
        /home/simon/.config/guix/profiles/emacs/emacs/bin/guix

At best it finds nothing.  Or worse, it could find an unexpected one
installed in one of my profiles – here from the package ’guix’.  And it
hides the error “No such file or directory”; for instance, it outputs:

        $ guix describe
        Generation 8    Oct 25 2023 14:23:41    (current)
          guix 4dfdd82
            repository URL: https://git.savannah.gnu.org/git/guix.git
            branch: master
            commit: 4dfdd822102690b5687acf28365ab707b68d9476

And I do not know where that comes from.  Another story.

Well, the current profiles reads,

--8<---------------cut here---------------start------------->8---
$ ls -1 /var/guix/profiles/per-user/simon/ | grep current
current-guix
current-guix-0-link
current-guix-29-link
--8<---------------cut here---------------end--------------->8---

And that profile numbered 0 newly created is empty:

--8<---------------cut here---------------start------------->8---
$ tree /var/guix/profiles/per-user/simon/current-guix-0-link
/var/guix/profiles/per-user/simon/current-guix-0-link
├── etc
│   └── profile
└── manifest

2 directories, 2 files
--8<---------------cut here---------------end--------------->8---


On Wed, 05 Jul 2023 at 17:21, Blake Shaw <blake <at> reproduciblemedia.com> wrote:

> But like, should this happen? Should we ever be rolling back to an
> empty "0" generation that doesn't even contain guix, and thus creates
> a pickle for those who don't have prior knowledge of how to get out of
> it? Should we limit gc --delete-generations to always keep a previous
> generation at hand, perhaps unless forced by some other flag, so that
> [in particular, new] users don't break their systems in the middle of
> the day and then have something to solve that encumbers their plans &
> work?

IMHO, it is an bug with “guix pull --roll-back”.  When the current
generation is the older one, then it should not be possible to
roll-back; or roll-back should do nothing in this corner case.

It should not be possible to create an empty profile numbered 0.


Cheers,
simon

This bug report was last modified 1 year and 265 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.