bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35380: disk-image fails to install efi grub


From: Marius Bakke
Subject: bug#35380: disk-image fails to install efi grub
Date: Fri, 03 May 2019 00:17:53 +0200
User-agent: Notmuch/0.28.3 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu)

Ludovic Courtès <address@hidden> writes:

> Hello,
>
> Gábor Boskovits <address@hidden> skribis:
>
>> 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
>> system. Wdyt?
>
> I suppose the file that contains variables could be temporary or
> read-only in the store?

Temporary yes, read only no :-)

EFI firmwares are inherently stateful: bootloaders are *required* to
update the NVRAM with the file name, UUID, and partition of the loader.

That means you can't just take an operating system hard drive from one
EFI system to another.  The new host system won't know where to find the
bootloader.  You have to use `efibootmgr` or similar to create an entry
for the hard drive in the firmware.  Maybe some firmwares are smarter...

One can launch a Guix EFI virtual machine "manually" by:
  qemu -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin foo.img

This will boot anything created by `guix system disk-image` because they
contain a generic UEFI loader in a standard location (using
grub-mkstandalone).  Now if you try to use GRUB-EFI-BOOTLOADER inside
this virtual machine, it will succeed, but complain that it cannot
update the EFI boot entries, resulting in a VM that cannot boot.

Copying the firmware file somewhere and making it writable will allow
you to persist the installation, as long as you carry that firmware file
around.  Or you can create a dedicated file for the variables and use it
with other firmware files -- but you can not boot the VM without it.

I'm not sure what use case rendaw had in mind, can you elaborate? 

It would be great to have UEFI support in the <virtual-machine> record,
mainly for system tests, but I doubt that is what rendaw is after :-)

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]