From mboxrd@z Thu Jan 1 00:00:00 1970 From: zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) Subject: Re: "guix deploy" is in git master Date: Mon, 08 Jul 2019 13:37:18 -0400 Message-ID: <87r270ig1d.fsf@sdf.lonestar.org> References: <87a7drn0ux.fsf@dustycloud.org> <874l3zse7o.fsf@elephly.net> <87wogujmld.fsf@elephly.net> <871rz19a4h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:36845) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkXa1-0004Ie-Ct for guix-devel@gnu.org; Mon, 08 Jul 2019 13:37:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkXa0-0005TI-6i for guix-devel@gnu.org; Mon, 08 Jul 2019 13:37:33 -0400 In-Reply-To: <871rz19a4h.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 07 Jul 2019 16:45:18 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ricardo Wurmus writes: > I tried again and it started building things but then aborted like this: >=20 > =E2=80=A6 > offloading '/gnu/store/x1q848ra6lm3y0ma9n2i73k8ic1gfyz9-references.drv' t= o '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-re= ferences' > done with offloaded '/gnu/store/x1q848ra6lm3y0ma9n2i73k8ic1gfyz9-referenc= es.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/=EF= =BF=BD=EF=BF=BD") > 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 # =EF=BF=BD=EF=BF=BD) > In guix/store.scm: > 1803:24 3 (run-with-store # _ # _ =EF= =BF=BD=EF=BF=BD) > In gnu/machine/ssh.scm: > 339:2 2 (_ _) > In guix/remote.scm: > 122:20 1 (_ _) > 66:17 0 (%remote-eval _ _) >=20 > 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 admini= strator\" home-directory: # create-home-direc= tory?: #t shell: \"/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/= bin/bash\" system?: #f>")] 1837f00>>)'. >=20 > Do you know what might be wrong here? Ludovic Court=C3=A8s writes: > I suspect the bug has nothing to do with =E2=80=98remote-eval=E2=80=99. N= amely, if the > machine you=E2=80=99re reconfigure is running Guix from before commit > 6061d01512081c93c53fdd1d4302b36696403061 (March 2019), then restart > the =E2=80=98user-homes=E2=80=99 services fails with this error for obscu= re 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl0jf04ACgkQ9Qb9Fp2P 2VrN2g/+LoFlSLGKR/L9eXYt8mS2YOLscTavSGYlPMelAb48zrvdqjbtnGqgCuee nQGkM62ItJn9J5IrK4uEU+FWQ7qEx6PKwtOnESwJx29dYdiw21EmWjFzo7maDxIa j94sDXbOHQRgBDZKLFC4Mvt5KDxzJnSAejUzbpcHdI+0oYotd4pkndVTN6C8YGUk x24m73hRRhkK1fIy043Jp8vIzKuNWqmt1cY01exrO1ejJWeK3p65q35g2GOHtvbP AWA/jcxq982HBWnkJ56kPYmFL/aVbRz6u+chnMOHbHYlFiMsS11k+1ufGwDTGuvN x98TF6eiIZz+0YPTZ3cn+DUkDh3tMaSvvKcFG7VC1uBh0sY801YvyiHNezwj+OJo w84aFdodkj+j434O51FfsX5zgzZsqjP/hJaQm78zyTEWaNV/AzZJjBkhZ2ZVDwAf EshqSlaM5e2vDi3miKEsRfS/hv05efZ1QeIvxXxBH8Qf6LU8yNQqZA19IqztCEeh hEc2dPkGicoemZhRC041Hb/6EGQzsn4a5kGZ3ZUwRl1w1CzLd1Ln46HbBN4S+iLL 5TM4GZofqFNmgW7awJeIrtHelPR5meKjMPXkQ4vMLoVJ1Afea5P4+mCpnAPzA9kG tyVsnunlNKUBsx/Zl54HkMbWSdXlMBe31NL2wNpRaoqULdgXTBI= =rnAc -----END PGP SIGNATURE----- --=-=-=--