Image generation

Image generation

[Mathieu Othacehe]

Hello,

I made some progress on the image generation topic. As discussed
previously, the goal is to use the same principles as genimage[1], to
achieve faster image generation, without resorting to VM.

A very related topic, is to bring the possibility to create Guix System
images with custom layouts. That includes position, size and type of the
bootloader partition, offset of the root partition and so on. While this
is not really important for desktop usage, it is almost mandatory for
embedded usage.

The wip-disk-image branch allows to define a Guix System image along the
lines of:

--8<---------------cut here---------------start------------->8---
(define my-image
  (image
   (format 'disk-image)
   (operating-system my-os)
   (partitions
    (list (partition
           (size (* 40 (expt 2 20)))
           (label "GNU-ESP")
           (file-system "vfat")
           (flags '(esp))
           (initializer (gexp initialize-efi-partition)))
          (partition
           (size 'guess)
           (label "Guix_image")
           (file-system "ext4")
           (flags '(boot))
           (initializer (gexp initialize-root-partition)))))))
--8<---------------cut here---------------end--------------->8---

then, you can call '(system-image my-image) and get a bootable
disk-image.

On this branch, it is already possible to generate an EFI disk-image,
with the traditional command:

--8<---------------cut here---------------start------------->8---
./pre-inst-env guix system disk-image gnu/system/examples/desktop.tmpl
--8<---------------cut here---------------end--------------->8---

On my computer, this takes 6m50 versus 2h30 for the master version. I
tested the image in QEMU, everything seems fine.

Now there's still plenty of work. This branch needs some more
cleaning. Then we need to:

* Add support for ISO images.
* Extend support to grub (non-efi), extlinux and u-boot bootloaders.
* Check everything works with --system and --target arguments.

I've re-implemented some parts of genimage in (gnu build disk-image)
module. Now, we could also go further and remove the use of this tool
completely.

Please tell me what you think,

Thanks,

Mathieu

[1]: https://github.com/pengutronix/genimage

Re: Image generation

[Leo Famulari]

On Tue, Apr 21, 2020 at 08:59:31PM +0200, Mathieu Othacehe wrote:
> On my computer, this takes 6m50 versus 2h30 for the master version. I
> tested the image in QEMU, everything seems fine.

Wow! Why did it take 2h30? Do you have KVM?

Re: Image generation

[Mathieu Othacehe]

> * Add support for ISO images.

For ISO images, by running make-iso9660-image directly on the host (see
wip-disk-image branch), I have a considerable time decrease.

This command:

--8<---------------cut here---------------start------------->8---
guix system disk-image --file-system-type=iso9660 gnu/system/examples/bare-bones.tmpl
--8<---------------cut here---------------end--------------->8---

takes,

* Without zisofs compression, on host: 4min
* With zisofs compression, on host: 8min
* With zisofs, on VM: 19min (master)

This makes me think that we may want to make iso compression optional,
so that tests can use uncompressed iso that takes more space but are
faster to produce.

It seems that there are also some alternatives to xorriso such as
genisoimage (used by genimage).

Mathieu

Re: Image generation

[Mathieu Othacehe]

> Wow! Why did it take 2h30? Do you have KVM?

Yes, I'm not sure why it's so long. It seems that
"estimated-partition-size" takes a large proportion of this time,
because if I run the same command with a fixed disk-image size it goes
faster.

Mathieu

Re: Image generation

[Ludovic Courtès]

Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> This command:
>
> guix system disk-image --file-system-type=iso9660 gnu/system/examples/bare-bones.tmpl
>
> takes,
>
> * Without zisofs compression, on host: 4min
> * With zisofs compression, on host: 8min
> * With zisofs, on VM: 19min (master)

Nice!

> This makes me think that we may want to make iso compression optional,
> so that tests can use uncompressed iso that takes more space but are
> faster to produce.
>
> It seems that there are also some alternatives to xorriso such as
> genisoimage (used by genimage).

To me it’s really Xorriso that’s terribly slow, much slower than what
‘guix system disk-image’ does for ext4 on master.

Ludo’.

Re: Image generation

[Ludovic Courtès]

Howdy!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> I made some progress on the image generation topic. As discussed
> previously, the goal is to use the same principles as genimage[1], to
> achieve faster image generation, without resorting to VM.

Awesome.

> A very related topic, is to bring the possibility to create Guix System
> images with custom layouts. That includes position, size and type of the
> bootloader partition, offset of the root partition and so on. While this
> is not really important for desktop usage, it is almost mandatory for
> embedded usage.
>
> The wip-disk-image branch allows to define a Guix System image along the
> lines of:
>
> (define my-image
>   (image
>    (format 'disk-image)
>    (operating-system my-os)
>    (partitions
>     (list (partition
>            (size (* 40 (expt 2 20)))
>            (label "GNU-ESP")
>            (file-system "vfat")
>            (flags '(esp))
>            (initializer (gexp initialize-efi-partition)))
>           (partition
>            (size 'guess)
>            (label "Guix_image")
>            (file-system "ext4")
>            (flags '(boot))
>            (initializer (gexp initialize-root-partition)))))))

That’s really cool!  I’ve been willing to have something like that
forever, but the current <partition> record is buried on the build side,
which makes it inconvenient to use like you do above.

> On this branch, it is already possible to generate an EFI disk-image,
> with the traditional command:
>
> ./pre-inst-env guix system disk-image gnu/system/examples/desktop.tmpl
>
> On my computer, this takes 6m50 versus 2h30 for the master version. I
> tested the image in QEMU, everything seems fine.

Oh, this much on ‘master’?  Anyway, the speedup is undoubtedly there and
it’s really great.

> Now there's still plenty of work. This branch needs some more
> cleaning. Then we need to:
>
> * Add support for ISO images.

I see you did that in the meantime.

> * Extend support to grub (non-efi), extlinux and u-boot bootloaders.
> * Check everything works with --system and --target arguments.

Yeah.

I saw your message to janneke, and indeed, I think there’s room for
cooperation: janneke has come up with something that’s very close to
“normal” Guix System for GNU/Hurd, and one of the main stumbling blocks
in my mind is building the image and in particular getting proper GRUB
suppotr for multiboot OSes.

> I've re-implemented some parts of genimage in (gnu build disk-image)
> module. Now, we could also go further and remove the use of this tool
> completely.

I think it’s great.  :-)

Please do ping us when you want a closer review!

Ludo’.

Re: Image generation

[Ludovic Courtès]

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> Wow! Why did it take 2h30? Do you have KVM?
>
> Yes, I'm not sure why it's so long. It seems that
> "estimated-partition-size" takes a large proportion of this time,
> because if I run the same command with a fixed disk-image size it goes
> faster.

Ooooh, I had never realized, but you may be right: ‘closure-size’ stats
every single file of the closure, and those files are accessed over 9P.

That said, I tried this:

--8<---------------cut here---------------start------------->8---
$ guix system build gnu/system/examples/bare-bones.tmpl --no-offload

[...]

$ time guix system disk-image gnu/system/examples/bare-bones.tmpl --no-offload
guix system: warning: Your Guix installation is 15 days old.
guix system: warning: Consider running 'guix pull' followed by
'guix system reconfigure' to get up-to-date packages and security updates.

La jenaj derivoj estos konstruataj:
   /gnu/store/ydvfhx9v65l4cjrbdgr6xxdh44091fwf-disk-image.drv
   /gnu/store/8kz750zdbxl86n4w2gfcm0xm6gcqzbnb-linux-vm-loader.drv
   /gnu/store/0jmcc2f6r3q72mlbi9ahmx2bjghn2rha-builder-in-linux-vm.drv
   /gnu/store/9df7312w32sbs9nv55x8arh2c65apjmx-grub.cfg.drv
   /gnu/store/72mmpjd65ysyxdb8c7x9bflb7g9jq93i-raw-initrd.drv
   /gnu/store/m4xri89s0m0xkdkbma1z0a9ikaz3117v-system.drv
   /gnu/store/53gm95vhr2p5r6g3bb7c7zynchwn2k3x-boot.drv
   /gnu/store/ylmkdd43vinyz6li8kx62cphz74kcark-parameters.drv
building /gnu/store/53gm95vhr2p5r6g3bb7c7zynchwn2k3x-boot.drv...
building /gnu/store/72mmpjd65ysyxdb8c7x9bflb7g9jq93i-raw-initrd.drv...
building /gnu/store/ylmkdd43vinyz6li8kx62cphz74kcark-parameters.drv...
building /gnu/store/m4xri89s0m0xkdkbma1z0a9ikaz3117v-system.drv...
building /gnu/store/9df7312w32sbs9nv55x8arh2c65apjmx-grub.cfg.drv...
building /gnu/store/0jmcc2f6r3q72mlbi9ahmx2bjghn2rha-builder-in-linux-vm.drv...
building /gnu/store/8kz750zdbxl86n4w2gfcm0xm6gcqzbnb-linux-vm-loader.drv...
building /gnu/store/ydvfhx9v65l4cjrbdgr6xxdh44091fwf-disk-image.drv...
/gnu/store/7v599g2zwkzb6lv8s6gjm66lqw0gcb53-disk-image

real	4m11.079s
user	0m5.145s
sys	0m0.418s
$ guix describe
Generacio 139	Apr 13 2020 21:50:08	(nuna)
  guix bad368b
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: bad368b0d794689f3a8a11b58f1ea4987938682e
--8<---------------cut here---------------end--------------->8---

So it’s much less than 2h30.  Could it be that you timing building of
additional derivations?  Even with a cold cache, it shouldn’t make that
big a difference no?

Thanks,
Ludo’.