From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: GuixSD on servers [Fwd: [rtracker.1984.is #131647] A question about VServer system specific requirements] Date: Wed, 19 Apr 2017 22:59:15 +0200 Message-ID: <8760i0m7vg.fsf@gnu.org> References: <20170418141719.llp77itz7vyq5rij@abyayala> <87k26hwxt0.fsf@gmail.com> 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]:43474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0wh7-0003Lm-Sq for guix-devel@gnu.org; Wed, 19 Apr 2017 16:59:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0wh4-0006hC-QM for guix-devel@gnu.org; Wed, 19 Apr 2017 16:59:21 -0400 In-Reply-To: <87k26hwxt0.fsf@gmail.com> (Chris Marusich's message of "Tue, 18 Apr 2017 08:16:43 -0700") 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: Chris Marusich Cc: guix-devel@gnu.org Heya, Chris Marusich skribis: > I've been looking into this off and on over the last few weeks, but I > haven't made any breakthroughs. The closest I got was this: > > 1) Create a disk image for testing: > > ./pre-inst-env guix system --root=3D/tmp/disk-image-gc-root --fallback = disk-image ~/guix/gnu/system/install.scm > cp $the_resulting_path /tmp/disk-image >=20=20=20 > 2) Try to boot it (with an attached hard disk), and watch it fail: > > qemu-img create -f qcow2 /tmp/test 10G > sudo qemu-system-x86_64 -machine type=3Dpc-i440fx-2.5,accel=3Dkvm -boot= order=3Ddc,menu=3Don -m size=3D4G -k en-us -name guixsd -cdrom "/tmp/disk-= image" "/tmp/test" > > 3) Mount it as loopback device: > > sudo losetup -P /dev/loop0 /tmp/disk-image > sudo mkdir /mnt/disk-image-partition-1 > sudo mount /dev/loop0p1 /mnt/disk-image-partition-1 >=20=20=20 > 4) Make a bootable CD-ROM image of it (see (grub) Invoking grub-mkrescue): > > sudo grub-mkrescue -o /tmp/test-img.iso /mnt/disk-image-partition-1 > > 5) Try to boot (partial success): > > sudo qemu-system-x86_64 -machine type=3Dpc-i440fx-2.5,accel=3Dkvm -boot= order=3Ddc,menu=3Don -m size=3D4G -k en-us -name guixsd -cdrom "/tmp/disk-= image" "/tmp/test" > > There appear to be (at least) two problem that prevent this naive > solution from working, which might point us in the right direction: > > First, the GRUB menu is trying to find a file system with label > "gnu-disk-image" (via "search --label --set gnu-disk-image"), which > won't work because there is no file system with that label in the > resulting image. So it seems that the crux of the problem is that ISO9660 lacks file system labels, which breaks the whole thing, right? > Possible fix: the manual for grub-mkrescue says "The > root device will be set up appropriately on entering your 'grub.cfg' > configuration file", so perhaps we can simply omit our --search. FYI, > the boot process continues successfully past this point precisely > because GRUB has already set the root; the fact that our search command > failed generates an error message but does not change the fact that it > succeeds in booting to the initrd. Good. > Second, the init process from the initrd (I think that's what it's > called?) is trying to look for a file system with label > "gnu-disk-image", which it never finds. It just sits there waiting to > find it, and it never shows up, so it freaks out. Possible solution: > modify the behavior of our initrd's init process. I'm not sure how to > customize the init process here, but there must be a way. We'll > probably also need the kernel module that enables reading of iso9660 > file systems, if it wasn't present already. So we could try detecting the root partition by a mechanism other than partition labels/UUIDs, but I don=E2=80=99t know which mechanism. Ideas? = How do people address this? > If you don't like grub-mkrescue, you can "roll your own" ISO generation > program, like Nix does by customizing the xorriso invocation [1]... But > honestly, it looks pretty complicated [2]. So if we can let > grub-mkrescue do that work for us, that would be swell. Indeed, though of course grub-mkrescue invokes xorriso behind the scenes. Once we=E2=80=99ve figured out the partition designation issue above, I gue= ss we could integrate that and have, say, guix system iso-image =E2=80=A6 to produce an ISO image. Sounds doable! Thanks for the explanations, Ludo=E2=80=99.