Ludovic Courtès <address@hidden
> ezt írta (időpont: 2019. máj. 1., Sze, 22:21):
rendaw <address@hidden> skribis:
> On 4/25/19 5:44 PM, Ludovic Courtès wrote:
>> Exactly: currently QEMU is run with a plain old BIOS, and not with the
>> UEFI firmware, so what you want is not implemented yet (see the comment
>> in gnu/system/vm.scm:799).
>> I’m closing this bug, but you can open a wishlist item about it if you
> I'm not going to comment on the wishlist thing, but this seems like a
> fairly huge problem:
> 1. The documentation doesn't mention this anywhere! Not in the
> bootloader docs, not in the disk-image docs, not in the "limitations",
> not in "hardware considerations"
> 2. I've spent several _days_ now digging through Guix source code and
> never found that message.
I’m sorry to hear that. I guess that the reason the documentation
doesn’t mention it is that users didn’t find it all that important.
My guess is that to many of us, using a VM is a way to test an OS, and
it doesn’t matter in that context whether the emulated machine uses a PC
BIOS or UEFI.
I understand that it does matter in some cases, so I agree we should
support it. I don’t know exactly what it would take, but if you have
ideas, they’d be welcome.
I've already looked into that earlier, and supporting this usecase would not be
so hard. We have ovmf after all, and we could stat qemu in efi mode. It would not
be so hard to get the thing in place to do an emergency efi booting setup.
Why I did not feel comfortable to carry on work in this direction, is that we should
associate a state with the VM-s, namely the file contatining the nvram variables of
the efi firmware. This is needed for full support, but not needed to create a bootable
We would also need an efi installation procedure, but this would also mean that we
could create an efi install system test, which would be really nice indeed.
Also the parameters should be extended to be able to select if we would like to generate
a bios or and efi image.
These are the thing from the top of my head, but it might well be that I am missing something.
> 3. The build still completes with a successful exit code. The only way
> to find out the image doesn't have a bootloader (-> is unusable) is to
> try to boot it
Yes, that’s an unfortunate bug reported here: