Re: GuixSD on servers [Fwd: [rtracker.1984.is #131647] A question about VServer system specific requirements]

[ludo@gnu.org (Ludovic Courtès)]

Heya,

Chris Marusich <cmmarusich@gmail.com> 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=/tmp/disk-image-gc-root --fallback disk-image ~/guix/gnu/system/install.scm
>   cp $the_resulting_path /tmp/disk-image
>   
> 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=pc-i440fx-2.5,accel=kvm -boot order=dc,menu=on -m size=4G -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
>   
> 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=pc-i440fx-2.5,accel=kvm -boot order=dc,menu=on -m size=4G -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’t 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’ve figured out the partition designation issue above, I guess we
could integrate that and have, say,

  guix system iso-image …

to produce an ISO image.  Sounds doable!

Thanks for the explanations,
Ludo’.