From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: 01/02: gnu: qemu: Update to 2.9.0 [security fixes]. Date: Thu, 20 Apr 2017 21:06:51 -0400 Message-ID: <87zifa602c.fsf@netris.org> References: <20170420182405.2682.82446@vcs0.savannah.gnu.org> <20170420182405.ED2D520740@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1N2V-000260-Ox for guix-devel@gnu.org; Thu, 20 Apr 2017 21:07:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1N2Q-0003zR-QY for guix-devel@gnu.org; Thu, 20 Apr 2017 21:07:11 -0400 Received: from world.peace.net ([50.252.239.5]:51091) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d1N2Q-0003zC-N6 for guix-devel@gnu.org; Thu, 20 Apr 2017 21:07:06 -0400 In-Reply-To: <20170420182405.ED2D520740@vcs0.savannah.gnu.org> (Leo Famulari's message of "Thu, 20 Apr 2017 14:24:05 -0400 (EDT)") 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 leo@famulari.name (Leo Famulari) writes: > lfam pushed a commit to branch master > in repository guix. > > commit dfa663c963a7c0745f18cbfab4b45eb335742602 > Author: Leo Famulari > Date: Fri Apr 7 09:03:28 2017 -0400 > > gnu: qemu: Update to 2.9.0 [security fixes]. > > Fixes CVE-2017-{5857,5973,5987,6058,6505,7377,7471,7718}. Thanks for this! Obviously it's an important security update, but: On my x86_64 system running GuixSD, 'grub' now fails to build from source. Three times in a row, the 'grub_cmd_set_date' has failed. Here's the relevant excerpt from test-suite.log (lightly formatted): FAIL: grub_cmd_set_date ======================= qemu-system-i386: Trying to execute code outside RAM or ROM at 0xefffff53 This usually means one of the following happened: (1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end (3) Your guest kernel has a bug and crashed by jumping off into nowhere This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. Execution cannot continue; stopping here. Test failed: 2017-04-21 00:08:44 Friday The build appears to have succeeded on Hydra: https://hydra.gnu.org/eval/109616?filter=grub Unfortunately the substitute is not yet available, so for the moment I'm stuck. I'll look into disabling this test for now. Has anyone else seen this? Mark