Re: "guix deploy" is in git master

[Jakob L. Kreuze]

Ricardo Wurmus <address@hidden> 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 <address@hidden> 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 <address@hidden> 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