guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#41350] [PATCH 0/3] Use native qemu to build vm-image.


From: Mathieu Othacehe
Subject: [bug#41350] [PATCH 0/3] Use native qemu to build vm-image.
Date: Tue, 19 May 2020 12:02:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello Jan,

>> Well first this 'vm-image' thing should be done in (gnu system image) as
>> soon as I have sorted out the bootloader issue. So the solution we will
>> find to overcome this Hurd issue will be temporary I hope.
>
> Can you elaborate a bit on that?  Do you think it makes sense to continue
> this temporary path some more (as it starts to work right now), or can we
> better abandon it and work the permanent solution?  How could I contribute?

Yes. Besides offering a more modular image creation API, the vocation of
(gnu system image) is to offer a way to generate all kind of Guix system
images (raw disk-images, ISO9660 images, Qemu images) without resorting
to VM for image creation.

Dropping VM, means that the image need to be build on the host, without
root permissions. This brings several limitations. If is no longer
possible to use "mount" for instance, or to call "grub-install".

To get around these limitations, I used the same strategy as Buildroot,
Yocto and OpenWrt that do not require root permissions to generate
disk-images.

For ISO9660 images:

* I first build the "image-root" derivation. It's a store directory that
contains the root file-system.

* Then, I call make-iso9660-image that, run GNU Xorriso on this
directory.

For raw disk-images:

* For each partition, I build the "partition-image-root"
  derivation. This is very similar to "image-root" but for the specified
  partition.

* For each partition root directory, I create the corresponding
  partition image, using tools such as mke2fs or mkdosfs depending on
  the partition file-system type.
  
* Then, I need to "assemble" the partitions in a disk-image. For that, I
  use "genimage" that will roughly use 'dd' to create a final disk-image
  with the partitions copied at the right offsets.
  
* The missing part here is the bootloader installation. As I mentioned,
  grub-install refuses to take a disk-image as argument (it requires a
  mounted partition). For EFI systems there's a work-around. The idea is
  to call grub-mkstandalone to create a Grub binary in the ESP
  partition. This Grub is configured to load the Grub configuration file
  located on the root file-system at /boot/grub/grub.cfg path.

Now back to the Hurd. I see that Debian is producing Hurd ISO images. We
could try to call `guix system disk-image --target=i586-pc-gnu
--file-system-type=iso9660 hurd.scm` and see if it works.

Regarding raw disk-image, I think we could try to produce EFI compatible
Hurd images. We could set the bootloader to grub-efi-bootloader in
%hurd-default-operating-system.

Finally, to produce raw disk-images with grub-minimal-bootloader or
grub-bootloader (what you are trying to do), we need to find a way to
make grub-install work on disk-images (MBR installation and so on). That
true for the Hurd but that's also true for Linux.

Sorry for the long explanation. Please tell me if something is not
clear.

The conclusion here is that, I think that we very few adaptations to
your branch, we should be able to produce Hurd ISO images or Hurd EFI
compatible disk-images. Maybe it would be a first step.

Then, we could find a way to create "MBR compatible" Hurd and Linux
disk-images in (gnu system image).

WDYT?

Thanks,

Mathieu





reply via email to

[Prev in Thread] Current Thread [Next in Thread]