From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: GuixSD on servers [Fwd: [rtracker.1984.is #131647] A question about VServer system specific requirements] Date: Sat, 22 Apr 2017 21:52:43 -0700 Message-ID: <87pog3u3ms.fsf@gmail.com> References: <20170418141719.llp77itz7vyq5rij@abyayala> <87k26hwxt0.fsf@gmail.com> <8760i0m7vg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d29W4-0007v1-Mt for guix-devel@gnu.org; Sun, 23 Apr 2017 00:52:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d29W1-0001DD-L7 for guix-devel@gnu.org; Sun, 23 Apr 2017 00:52:56 -0400 In-Reply-To: <8760i0m7vg.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 19 Apr 2017 22:59:15 +0200") 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@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: >> 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? Yes, probably. It seems we can set a "volume id", but not a label like in EXT file systems. For example, see here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/cd-dvd= /iso-image.nix >> 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? Volume ID seems like the right thing to try first. What do we need to change to support this, I wonder? I'm not familiar with the initrd stuff but would be willing to poke around in there and experiment. I just don't really know where to begin. >> 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 g= uess we > could integrate that and have, say, > > guix system iso-image =E2=80=A6 > > to produce an ISO image. Sounds doable! Yeah, that'd be cool. It looks like with the right incantations (see Nix's scripts), you can create a "hybrid" ISO image that boots correctly in PC-BIOS, UEFI, from CD/DVD or USB stick. But any ISO image that will boot from a CD is a good start. By the way, do you think it's possible to build an ISO image from a manifest of files? I ask because it seems like that's what Nix is doing; however, the code involved in 'guix system disk-image' seems to actually boot the target system before the final disk image is built. I was playing around by mounting the disk image as a loopback device only because that provided me with a convenient way to access all the files that need to be in a bootable system; it seems to me like it would be great if we could build an ISO image without first building an entire disk image. That seems redundant. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlj8MxsACgkQ3UCaFdgi Rp0aRhAAjV5omLfOq15ARPoXlNiEoEBi9iWC4OFZjhICJKUTl4Mws8hNiOMeysCQ 6KN2tGw8XsthzBiOK9M8Wd60h7qWpXqDRno2zegauEQnOh/12WCTm9jeCd30Cq+o GUWqSAFLW+IxQWmKaPk0xcObun5DgaWbmS7wNYE1DdEH5xyrM1jO3ds9Iclwj93i BwmXYYDa2NO2H9mISoywzcF5dY8xgjYO0scG3mHpZvNtupmWgncGBMssLawEhmb4 LsHTIP+rsp57zb//PTI8EuPdYgZB5bavUN5o8MbqCMkLtrCqk/AwER8gxKvT9y++ YpgZAoe/R/Z6Z9XCyJ8FyTV+bbrr64NkAzuTLtUb/ZmEQpDlZ7zFGEZ9mxomsEFv xX2gFrVkgFsBywrkRjo5NbGFkuJpfzMQTCHe3ZQdgTtVFYg3IW755xS4US2tztE1 KGyBQzqdRnSV5YBgyRRn0WbK8/2dTyUe29OimZTL5XJCf9Qt7ShqR/275tn9GT9Q tN9p5m4E66OPNM3pOVl0qUR3CTenYNA1s29WmgSD2DdI9/CnYDMyPkvToh43oMDW LtsXg5BdkrmxWx0tW8whFI+8UiQ5akR7DIoM5JjNN4iMqTYASJtjyill2vWs9rkT TMPrNi/BncKbGSFDOpyfKKKred8g2BqrAEuQh6SupgtjRl5jCzY= =QvS2 -----END PGP SIGNATURE----- --=-=-=--