Ricardo Wurmus <rek...@elephly.net> 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 #<procedure 3a8e500 at guix/scripts/deploy.s��> ��)
> In guix/store.scm:
> 1803:24 3 (run-with-store #<store-connection 256.99 252e3c0> _ # _ ��)
> 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 `(#<inferior-object #<condition
> &action-exception-error [service: user-homes action: start key: match-error
> args: ("match" "no matching pattern" "#<<user-account> name: \"root\"
> password: \"\" uid: 0 group: \"root\" supplementary-groups: () comment:
> \"System administrator\" home-directory: #<procedure home-directory (x)>
> 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 <l...@gnu.org> 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 <rek...@elephly.net> 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
signature.asc
Description: PGP signature
