From mboxrd@z Thu Jan 1 00:00:00 1970 From: George myglc2 Clemmer Subject: Re: Installation Date: Wed, 17 Jan 2018 21:29:28 -0500 Message-ID: <86y3kvzypj.fsf@gmail.com> References: <87mv1c4kp7.fsf@gnu.org> 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]:51557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebzxR-0007vj-VM for guix-devel@gnu.org; Wed, 17 Jan 2018 21:29:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebzxN-00031K-Ty for guix-devel@gnu.org; Wed, 17 Jan 2018 21:29:37 -0500 In-Reply-To: <87mv1c4kp7.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 17 Jan 2018 15:35:32 +0100") 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 On 01/17/2018 at 15:35 Ludovic Court=C3=A8s writes: > Hi G=C3=A1bor, > > G=C3=A1bor Boskovits skribis: > >> I believe, that we could make a powerful extension to guixsd if we could= do >> an installation from an installation description. >> >> I think this installation description should look like the operating-sys= tem description we >> already have. > > In what way would it defer? :-) > > =E2=80=98operating-system=E2=80=99 *is* an =E2=80=9Cinstallation descript= ion.=E2=80=9D War story, FWIW: In the past I have upgraded systems from Guix/Debian and and from GuixSD to new system disks by simply doing 'guix system init config.scm'. I found this a lot easier than using an install disk. The only problem I hit was that removing the original system disk caused the boot to hang but putting it back into the original slot and pointing the the BIOS at the new disk booted just fine from the new disk. The behavior I observed at the time is described in bug#23072: https://lists.gnu.org/archive/html/bug-guix/2016-03/msg00182.html IIRC the details are: when running on a system disk (say: /dev/sda) and installing to new disk (say: /dev/sdb) you must set the bootloader target to /dev/sdb so the boot loader will be copied to the new system disk. But, at least on my servers, when I remove the original system disk, the new disk system becomes /dev/sda, and the bootloader fails. Presumably this happens when, at boot time, the previously specified target no longer matches the current deviceID of the actual boot device. I am actively interested in perfecting my understanging of this topic because I am about to overhall my server configs, and plan to use the approach again. So Ludo=E2=80=99, if you see faulty logic above I would lov= e to hear about it. TIA - George