Ricardo Wurmus writes: > I tried again and it started building things but then aborted like this: > > … > offloading '/gnu/store/x1q848ra6lm3y0ma9n2i73k8ic1gfyz9-references.drv' to '141.80.167.145'... > @ build-remote /gnu/store/x1q848ra6lm3y0ma9n2i73k8ic1gfyz9-references.drv 141.80.167.145 > retrieving 1 store item from '141.80.167.145'... > importing file or directory '/gnu/store/1bm51aa2knvpp4b7kls0m6v19mmhb910-references'... > found valid signature for '/gnu/store/1bm51aa2knvpp4b7kls0m6v19mmhb910-references' > done with offloaded '/gnu/store/x1q848ra6lm3y0ma9n2i73k8ic1gfyz9-references.drv' > sending 47 store items (240 MiB) to '141.80.167.145'... > [ 1/ 2] Loading './gnu/services/herd.scm'... > [ 2/ 2] Compiling './gnu/services/herd.scm'... > sending 3 store items (0 MiB) to '141.80.167.145'... > Backtrace: > 7 (primitive-load "/home/rekado/.config/guix/current/bin/��") > In guix/ui.scm: > 1655:12 6 (run-guix-command _ . _) > In guix/store.scm: > 623:10 5 (call-with-store _) > In srfi/srfi-1.scm: > 640:9 4 (for-each # ��) > In guix/store.scm: > 1803:24 3 (run-with-store # _ # _ ��) > In gnu/machine/ssh.scm: > 339:2 2 (_ _) > In guix/remote.scm: > 122:20 1 (_ _) > 66:17 0 (%remote-eval _ _) > > guix/remote.scm:66:17: In procedure %remote-eval: > Throw to key `srfi-34' with args `(# name: \"root\" password: \"\" uid: 0 group: \"root\" supplementary-groups: () comment: \"System administrator\" home-directory: # create-home-directory?: #t shell: \"/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash\" system?: #f>")] 1837f00>>)'. > > Do you know what might be wrong here? Ludovic Courtès writes: > I suspect the bug has nothing to do with ‘remote-eval’. Namely, if the > machine you’re reconfigure is running Guix from before commit > 6061d01512081c93c53fdd1d4302b36696403061 (March 2019), then restart > the ‘user-homes’ services fails with this error for obscure reasons > that I forgot. The throw is coming from 'upgrade-shepherd-services' making a call to 'start-service', so I think that Ludovic is on the right track. What version of Guix is the remote running, Ricardo? If it's a recent commit, I worry that a bad 'user-homes' service file was sent over, or perhaps not sent over at all... Regardless, it's undesirable to have the deployment aborted half-way through. Ludovic -- I've wrapped my calls to 'unload-service' in 'false-if-exception'. Would it make sense to do something similar with my calls to 'start-service'? Perhaps giving the user a warning that certain services in the deployment were not started? > At any rate, I think the service upgrade phase happens after the > symlink-switch and bootloader installation (right?), in which case > reconfiguration is complete anyway. Uh oh. I suppose this is another reason for 'upgrade-shepherd-services' to be made more robust. 'upgrade-shepherd-services' occurs after the generation symlinks are switched, but before the bootloader installation. I copied the order from 'guix system reconfigure', but now I'm thinking that it may make more sense to upgrade services after installing the bootloader. All this is to say that Ricardo has successfully deployed a new system generation, but there's no bootloader entry for it. So if the machine is rebooted, it will load the previous generation. As a side note, congratulations on being the first person to upgrade a machine with 'guix deploy', Ricardo! Ricardo Wurmus writes: > Another thing I noticed is that an SSH authentication error prints a > backtrace. It would be nice if a failure to authenticate would be > communicated with a clearer error message. Agreed. It should be a simple enough patch, anyway. Thanks for the suggestion! Regards, Jakob