From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Removing corrupted items from a mirror Date: Sun, 24 Jul 2016 23:18:20 +0200 Message-ID: <87fuqyag6b.fsf@gnu.org> References: <20160724002620.GC26863@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRQn6-0007wf-4C for guix-devel@gnu.org; Sun, 24 Jul 2016 17:18:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRQn1-00081H-SU for guix-devel@gnu.org; Sun, 24 Jul 2016 17:18:26 -0400 In-Reply-To: <20160724002620.GC26863@jasmine> (Leo Famulari's message of "Sat, 23 Jul 2016 20:26:20 -0400") 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: Leo Famulari Cc: guix-devel@gnu.org Hi! Leo Famulari skribis: > My question is: How can I remove this corrupted file from the mirror? I > don't know how to figure the name of the file to remove. So first, note that there=E2=80=99s a narinfo cache in /var/guix/substitute/cache. First step is to rm -rf that. Next, you can remove all the narinfo cache of your nginx instance. If that=E2=80=99s unreasonable, you can find the file corresponding to the fau= lty narinfo by grepping it in the nginx cache. So in your case: > Found valid signature for /gnu/store/vsrcn35rjpgrrak1w31m7yhc12zz3hd1-cor= eutils-8.24 > From https://my-mirror/nar/vsrcn35rjpgrrak1w31m7yhc12zz3hd1-coreutils-8.24 =E2=80=A6 you would: cd /var/cache/nginx/narinfo grep -r vsrcn35rjpgrrak1w31m7yhc12zz3hd1 . rm the-file-that-matches Not very convenient! I realize I=E2=80=99m answering a slightly different question, because your problem is: > @ substituter-failed /gnu/store/vsrcn35rjpgrrak1w31m7yhc12zz3hd1-coreutil= s-8.24 0 hash mismatch in downloaded path `/gnu/store/vsrcn35rjpgrrak1w31m7= yhc12zz3hd1-coreutils-8.24': expected a91641b020926f42d7dcbe6e9d82be3b5d39f= 401b7328ea6d0cd79f7893aabb0, got fc8cf24465d8a97fef7cc41dfccddca158b6258ad0= e0929e002552d258dec7da That is, you got a binary whose content do not match what the narinfo advertises. That can happen with non-deterministic build processes, which I think is the case with Coreutils. Namely, we can have this scenario: 1. nginx caches the narinfo for coreutils, which contains the hash of a first build; 2. first build is removed from the machine that nginx mirrors; 3. a second build is performed on that machine, leading different contents (different hash); 4. Guix client requests coreutils binary, gets narinfo with old hash and contents with new hash, and errors out. I=E2=80=99ve never seen this happen on mirror.hydra.gnu.org, but anyway, our best protection is reproducible builds. In the meantime, removing the old narinfo from nginx=E2=80=99s cache would = help. HTH! Ludo=E2=80=99.