Hi Ludo, guix pull --roll-back did not solve the issue. The only thing I believe to have changed is the "host version" portion of the error message. 'which guix' actually points to ~/.configu/guix/current/bin/guix. Should this command yield a different value? I have actually not done anything regarding either guix-daemon or offloading. The only things I did after the fresh install were a reconfigure and passing a manifest file to 'guix package -m'. I may have misunderstood what Jakub wrote because I am unsure what a transient failure is. The portion I believe to have understood essentially says "try again later and it should work". I found the logs of 'compute-guix-derivation', but I was unable to see anything meaningful opening the .drv.bz2 file in emacs. Am I doing something wrong? I wont be on my guix machine for some days now but appreciate pointers. :) Olivier On 05.06.2020 18:29, Ludovic Courtès wrote: > Hi, > > o.rojon@posteo.net skribis: > >> Just to follow up: a roll-back does NOT solve the issue. >> >> What I have tried: >> 1) roll-back via guix system roll-back (to the generation that was >> created upon system installation) >> 2) roll-back via guix package --roll-back (same) >> 3) (1) + (2) combined >> 4) boot into the generation created upon system installation. >> >> In none of these cases was I able to run 'guix pull'. > > Thanks for testing this. > > Note that, if “which guix” returns ~/.config/guix/current/bin/guix, > then > none of the rollbacks above can have any effect. What could make a > difference (but again, that would seem weird to me) is: > > guix pull --roll-back > > Are you passing extra options to guix-daemon, such as > ‘--cache-failures’? Or did you enable offloading? > > It could also be that a transient failure is causing a silent build > failure somewhere, as Jakub suggests. > > Thanks, > Ludo’. > > PS: Please keep the bug address Cc’d.