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 --]
next prev parent 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
List information: https://guix.gnu.org/
* 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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).