unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Gábor Boskovits" <boskovits@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 35380-done@debbugs.gnu.org, rendaw <7e9wc56emjakcm@s.rendaw.me>
Subject: bug#35380: disk-image fails to install efi grub
Date: Thu, 2 May 2019 11:05:00 +0200	[thread overview]
Message-ID: <CAE4v=pgYYFYSwbQt6EdJ-fGD_-yvdxzN7Ooy-NiWB_ScELeKWA@mail.gmail.com> (raw)
In-Reply-To: <87d0l2exld.fsf@gnu.org>

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

Hello,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. máj. 1., Sze,
22:21):

> Hi rendaw,
>
> rendaw <7e9wc56emjakcm@s.rendaw.me> 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
> >> want!
> >>
> >> Thanks,
> >> Ludo’.
> >
> > 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
system. Wdyt?

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:
> <https://issues.guix.info/issue/34276>.
>
> Thanks,
> Ludo’.
>
>
>
> Best regards,
g_bor

[-- Attachment #2: Type: text/html, Size: 3724 bytes --]

  reply	other threads:[~2019-05-02  9:06 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 [this message]
2019-05-02 15:16         ` Ludovic Courtès
2019-05-02 22:17           ` Marius Bakke
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='CAE4v=pgYYFYSwbQt6EdJ-fGD_-yvdxzN7Ooy-NiWB_ScELeKWA@mail.gmail.com' \
    --to=boskovits@gmail.com \
    --cc=35380-done@debbugs.gnu.org \
    --cc=7e9wc56emjakcm@s.rendaw.me \
    --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).