bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”

bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”

[Ricardo Wurmus]

I’m trying to build a more recent VM image than 1.4.0.  The 1.4.0 qcow2
image that’s available for download on the Guix website boots fine, but
any image created with a current Guix cannot be booted.

I’m on Guix commit be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b.

I ran

    ./pre-inst-env guix system image -t qcow2 \
        doc/os-config-lightweight-desktop.texi

to generate the VM image and then I used

    qemu-system-x86_64 -enable-kvm \
                       -m 4096 -monitor stdio \
                       -drive file=/tmp/guixvm.qcow2,id=myhd \
                       -vnc :1

and connected Remmina to :1.

The fan spins up to top speed and I see “Booting from Hard Disk…” with
no progress whatsoever.

-- 
Ricardo

bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> I’m trying to build a more recent VM image than 1.4.0.  The 1.4.0 qcow2
> image that’s available for download on the Guix website boots fine, but
> any image created with a current Guix cannot be booted.
>
> I’m on Guix commit be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b.
>
> I ran
>
>     ./pre-inst-env guix system image -t qcow2 \
>         doc/os-config-lightweight-desktop.texi

Interestingly, the configuration in doc/os-config-bare-bones.texi does
boot fine.

-- 
Ricardo

bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> I’m trying to build a more recent VM image than 1.4.0.  The 1.4.0 qcow2
> image that’s available for download on the Guix website boots fine, but
> any image created with a current Guix cannot be booted.
>
> I’m on Guix commit be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b.
>
> I ran
>
>     ./pre-inst-env guix system image -t qcow2 \
>         doc/os-config-lightweight-desktop.texi
>
> to generate the VM image and then I used
>
>     qemu-system-x86_64 -enable-kvm \
>                        -m 4096 -monitor stdio \
>                        -drive file=/tmp/guixvm.qcow2,id=myhd \
>                        -vnc :1
>
> and connected Remmina to :1.
>
> The fan spins up to top speed and I see “Booting from Hard Disk…” with
> no progress whatsoever.

There have been recent changes in this area:

  6bd17a0806 image: Do not allow BIOS bootloader and GPT.
  e5ed1712da image: Introduce the mbr-hybrid-raw image type.

The latter changes the default image type.  Before that, there was:

  d57cab7641 image: Add mbr-raw-image-type and use by default.

I’m not sure if this could explain the problem.

Ludo’.

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> I’m trying to build a more recent VM image than 1.4.0.  The 1.4.0 qcow2
>> image that’s available for download on the Guix website boots fine, but
>> any image created with a current Guix cannot be booted.
>>
>> I’m on Guix commit be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b.
>>
>> I ran
>>
>>     ./pre-inst-env guix system image -t qcow2 \
>>         doc/os-config-lightweight-desktop.texi
>>
>> to generate the VM image and then I used
>>
>>     qemu-system-x86_64 -enable-kvm \
>>                        -m 4096 -monitor stdio \
>>                        -drive file=/tmp/guixvm.qcow2,id=myhd \
>>                        -vnc :1
>>
>> and connected Remmina to :1.
>>
>> The fan spins up to top speed and I see “Booting from Hard Disk…” with
>> no progress whatsoever.
>
> There have been recent changes in this area:
>
>   6bd17a0806 image: Do not allow BIOS bootloader and GPT.
>   e5ed1712da image: Introduce the mbr-hybrid-raw image type.
>
> The latter changes the default image type.  Before that, there was:
>
>   d57cab7641 image: Add mbr-raw-image-type and use by default.
>
> I’m not sure if this could explain the problem.

It’s due to the bootloader.  This field from the bare bones template
works:

  (bootloader (bootloader-configuration
                (bootloader grub-bootloader)
                (targets '("/dev/sdX"))))

but this from the desktop template doesn’t:

  (bootloader (bootloader-configuration
                (bootloader grub-efi-bootloader)
                (targets '("/boot/efi"))))

The manual for “guix system” gives a somewhat complicated invocation
that I only found out about later:

          image=$(guix system image --image-type=qcow2 \
                  gnu/system/examples/lightweight-desktop.tmpl)
          cp $image /tmp/my-image.qcow2
          chmod +w /tmp/my-image.qcow2
          qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
                             -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin

I haven’t tried it yet, but I assume that providing this extra “-bios”
option would fix it.  It wasn’t necessary before, though, and I think
it’s an inconvenient complication when running Guix VMs.

Perhaps an example invocation of qemu-system-* could be added as a
comment to the templates?

-- 
Ricardo

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> The manual for “guix system” gives a somewhat complicated invocation
> that I only found out about later:
>
>           image=$(guix system image --image-type=qcow2 \
>                   gnu/system/examples/lightweight-desktop.tmpl)
>           cp $image /tmp/my-image.qcow2
>           chmod +w /tmp/my-image.qcow2
>           qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
>                              -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin
>
> I haven’t tried it yet, but I assume that providing this extra “-bios”
> option would fix it.  It wasn’t necessary before, though, and I think
> it’s an inconvenient complication when running Guix VMs.

It means that ‘--image-type=qcow2’ can now end up creating EFI images.
Perhaps not so bad in practice since you can still create MBR images,
AIUI?

> Perhaps an example invocation of qemu-system-* could be added as a
> comment to the templates?

Yes, except maybe for those templates that are used as examples under
“Using the Configuration System”.

Ludo’.

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Mathieu Othacehe]

Hey,

Some context around that.

Before recent commits, when we were producing qcow2 or raw images,
those were MBR images with an EFI partition. If the grub-bootloader
was used, then Grub was installed both in the post-MBR gap
and in the EFI partition. This means that a single image could be booted
with or without the qemu -bios option, i.e both in BIOS legacy
or in EFI mode.

Commit d57cab764122af69d52d8cc9c843456044e5d7bc changed the default
behaviour and the produced images were by default MBR images, without
EFI partitions.

I changed that with e5ed1712da049b1c3dcf01e0a7e02e48a8aff012 and
dfaeaae9c7e7283b99ad10aef3e61402e9820bc7 which introduced a new image
type called mbr-hybrid-raw, which is now the default image type,
restoring the previous behaviour.

Now it looks to me that what Ricardo is observing is not linked to any
of the changes mentioned above.  When using the grub-efi-bootloader,
Grub is never installed in the post-MBR gap. This was already the case
in 1.4.0 and is still true. Those images cannot be booted without the
qemu -bios option unless I'm mistaken.

Hope it helps,

Mathieu

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Ricardo Wurmus]

Mathieu Othacehe <othacehe@gnu.org> writes:

> Now it looks to me that what Ricardo is observing is not linked to any
> of the changes mentioned above.  When using the grub-efi-bootloader,
> Grub is never installed in the post-MBR gap. This was already the case
> in 1.4.0 and is still true. Those images cannot be booted without the
> qemu -bios option unless I'm mistaken.

FWIW I tried the 1.4.0 image at
https://ftpmirror.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2,
which did boot just fine.

I suppose that one isn’t using the grub-efi-bootloader.

It’s quite possible that I’m one of only few people who are unaware of
the “-bios” option to qemu.  So there really isn’t any bug or regression
here, it’s just that my primitive mental model (use “guix system” to
build a VM, run with qemu) had not required upgrading until now.

For the benefit of people like me or newcomers perhaps the documentation
could make the dependency between the use of the grub-efi-bootloader and
additionally required qemu arguments a little clearer.

-- 
Ricardo

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Maxim Cournoyer]

Hi,

[...]

> It’s due to the bootloader.  This field from the bare bones template
> works:
>
>   (bootloader (bootloader-configuration
>                 (bootloader grub-bootloader)
>                 (targets '("/dev/sdX"))))
>
> but this from the desktop template doesn’t:
>
>   (bootloader (bootloader-configuration
>                 (bootloader grub-efi-bootloader)
>                 (targets '("/boot/efi"))))
>
> The manual for “guix system” gives a somewhat complicated invocation
> that I only found out about later:
>
>           image=$(guix system image --image-type=qcow2 \
>                   gnu/system/examples/lightweight-desktop.tmpl)
>           cp $image /tmp/my-image.qcow2
>           chmod +w /tmp/my-image.qcow2
>           qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
>                              -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin

Ah, I remember tripping on this.  GNOME Boxes can be built with ovmf
support and be able to boot with either a BIOS or UEFI bootloader but
bare QEMU cannot do so (and upstream appeared keen on keeping QEMU dumb
and keep the nicer abstractions for virtual-manager or GNOME Boxes
(maybe that's handled by libvirtd, I don't know).

> I haven’t tried it yet, but I assume that providing this extra “-bios”
> option would fix it.  It wasn’t necessary before, though, and I think
> it’s an inconvenient complication when running Guix VMs.
>
> Perhaps an example invocation of qemu-system-* could be added as a
> comment to the templates?

Or a simple nudge to the reference in the info manual?  This would avoid
duplicating the information (easing maintenance).  I think there's a way
to format it so that it opens directly as a URL in Emacs at least,
though I don't know the details.

-- 
Thanks,
Maxim