all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Marius Bakke <mbakke@fastmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>,
	"Gábor Boskovits" <boskovits@gmail.com>
Cc: 35380-done@debbugs.gnu.org, rendaw <7e9wc56emjakcm@s.rendaw.me>
Subject: bug#35380: disk-image fails to install efi grub
Date: Fri, 03 May 2019 00:17:53 +0200	[thread overview]
Message-ID: <87d0l0fqlq.fsf@fastmail.com> (raw)
In-Reply-To: <875zqsvqcb.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

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

> Hello,
>
> Gábor Boskovits <boskovits@gmail.com> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2019-05-02 22:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-22 16:06 bug#35380: disk-image fails to install efi grub rendaw
     [not found] ` <handler.35380.B.155594918611499.ack@debbugs.gnu.org>
2019-04-22 17:11   ` bug#35380: Acknowledgement (disk-image fails to install efi grub) rendaw
2019-04-25  8:44 ` bug#35380: disk-image fails to install efi grub Ludovic Courtès
2019-04-25 10:27   ` rendaw
2019-05-01 20:19     ` Ludovic Courtès
2019-05-02  9:05       ` Gábor Boskovits
2019-05-02 15:16         ` Ludovic Courtès
2019-05-02 22:17           ` Marius Bakke [this message]
2019-05-03 13:18             ` rendaw
2019-05-03 15:10               ` Marius Bakke
2019-05-04  3:42                 ` rendaw
2019-05-04 14:34                   ` Marius Bakke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d0l0fqlq.fsf@fastmail.com \
    --to=mbakke@fastmail.com \
    --cc=35380-done@debbugs.gnu.org \
    --cc=7e9wc56emjakcm@s.rendaw.me \
    --cc=boskovits@gmail.com \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.