From mboxrd@z Thu Jan 1 00:00:00 1970 From: cmmarusich@gmail.com Subject: Fix a boot problem reported by ng0 Date: Thu, 3 Nov 2016 06:10:27 -0700 Message-ID: <20161103131028.7984-1-cmmarusich@gmail.com> References: <20161103001936.GA24164@jasmine> Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2Hn6-0002y5-UF for guix-devel@gnu.org; Thu, 03 Nov 2016 09:10:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2Hn6-0001eN-4b for guix-devel@gnu.org; Thu, 03 Nov 2016 09:10:48 -0400 In-Reply-To: <20161103001936.GA24164@jasmine> 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: guix-devel@gnu.org As you know, ng0 was having trouble booting into GuixSD after 1ef8b72a7f87afe7cffe52393d99e1b14e4770e1. When I looked closely at the change, I realized we were not doing the right thing in all cases. Here is a patch to fix that. I've confirmed via manual testing in a QEMU image that when using a device path for the file system containing the store, 'guix system reconfigure' does the right thing: it uses a file-based GRUB root search in the new GRUB menu entry. That's what it originally did, but 1ef8b72a7f87afe7cffe52393d99e1b14e4770e1 broke that behavior. I didn't catch this regression because our existing system tests did not catch it, and in all my manual tests, I was using file system labels, not device paths. -- Chris