Cannot boot any recent VM built with “guix system image -t qcow2”

  • Open
  • quality assurance status badge
Details
4 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mathieu Othacehe
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Ricardo Wurmus
Severity
important

Debbugs page

R
R
Ricardo Wurmus wrote on 26 Sep 2023 00:32
(name . bug-guix)(address . bug-guix@gnu.org)
87jzsd4c1b.fsf@elephly.net
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
R
R
Ricardo Wurmus wrote on 26 Sep 2023 00:48
(address . 66207@debbugs.gnu.org)
87fs314bm8.fsf@elephly.net
Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (11 lines)
> 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
L
L
Ludovic Courtès wrote on 30 Sep 2023 02:47
control message for bug #66207
(address . control@debbugs.gnu.org)
87jzs8uh51.fsf@gnu.org
severity 66207 important
quit
L
L
Ludovic Courtès wrote on 30 Sep 2023 03:03
Re: bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 66207@debbugs.gnu.org)
87wmw8t1ut.fsf@gnu.org
Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (23 lines)
> 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’.
R
R
Ricardo Wurmus wrote on 30 Sep 2023 13:39
Re: bug#66207: Cannot boot VMs with grub-efi-bootloader
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 66207@debbugs.gnu.org)
877co7s7vc.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (38 lines)
> 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
L
L
Ludovic Courtès wrote on 1 Oct 2023 08:17
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 66207@debbugs.gnu.org)
87h6nas77g.fsf@gnu.org
Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (14 lines)
> 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?

Toggle quote (3 lines)
> 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’.
M
M
Maxim Cournoyer wrote on 1 Oct 2023 12:51
(name . Ricardo Wurmus)(address . rekado@elephly.net)
875y3q6s06.fsf@gmail.com
Hi,

[...]

Toggle quote (23 lines)
> 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).

Toggle quote (7 lines)
> 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
M
M
Mathieu Othacehe wrote on 1 Oct 2023 13:21
(name . Ludovic Courtès)(address . ludo@gnu.org)
87v8bq6ql7.fsf@gnu.org
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
R
R
Ricardo Wurmus wrote on 1 Oct 2023 13:59
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87ttraqchb.fsf@elephly.net
Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (6 lines)
> 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
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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 66207@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66207
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch