Acknowledgement sent
to Ricardo Wurmus <rekado@elephly.net>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Tue, 26 Sep 2023 07:42:01 GMT) (full text, mbox, link).
Subject: Cannot boot any recent VM built with “guix
system image -t qcow2”
Date: Tue, 26 Sep 2023 09:32:49 +0200
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
Information forwarded
to bug-guix@gnu.org: bug#66207; Package guix.
(Tue, 26 Sep 2023 07:51:02 GMT) (full text, mbox, link).
Subject: Re: Cannot boot any recent VM built with “guix
system image -t qcow2”
Date: Tue, 26 Sep 2023 09:48:46 +0200
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
Severity set to 'important' from 'normal'
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Sat, 30 Sep 2023 09:49:01 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#66207; Package guix.
(Sat, 30 Sep 2023 10:04:02 GMT) (full text, mbox, link).
Subject: Re: bug#66207: Cannot boot any recent VM built with
“guix system image -t qcow2”
Date: Sat, 30 Sep 2023 12:03:06 +0200
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’.
Information forwarded
to bug-guix@gnu.org: bug#66207; Package guix.
(Sat, 30 Sep 2023 20:52:02 GMT) (full text, mbox, link).
Subject: Re: bug#66207: Cannot boot VMs with grub-efi-bootloader
Date: Sat, 30 Sep 2023 22:39:41 +0200
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
Information forwarded
to bug-guix@gnu.org: bug#66207; Package guix.
(Sun, 01 Oct 2023 15:18:02 GMT) (full text, mbox, link).
Subject: Re: bug#66207: Cannot boot VMs with grub-efi-bootloader
Date: Sun, 01 Oct 2023 17:17:23 +0200
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’.
Information forwarded
to bug-guix@gnu.org: bug#66207; Package guix.
(Sun, 01 Oct 2023 19:52:01 GMT) (full text, mbox, link).
Subject: Re: bug#66207: Cannot boot VMs with grub-efi-bootloader
Date: Sun, 01 Oct 2023 15:51:21 -0400
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
Information forwarded
to bug-guix@gnu.org: bug#66207; Package guix.
(Sun, 01 Oct 2023 20:23:01 GMT) (full text, mbox, link).
Subject: Re: bug#66207: Cannot boot VMs with grub-efi-bootloader
Date: Sun, 01 Oct 2023 22:21:56 +0200
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
Information forwarded
to bug-guix@gnu.org: bug#66207; Package guix.
(Sun, 01 Oct 2023 21:07:02 GMT) (full text, mbox, link).
Subject: Re: bug#66207: Cannot boot VMs with grub-efi-bootloader
Date: Sun, 01 Oct 2023 22:59:21 +0200
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
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.