GNU bug report logs - #35380
disk-image fails to install efi grub

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35380 in the body.
You can then email your comments to 35380 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: rendaw <7e9wc56emjakcm <at> s.rendaw.me>
To: submit <at> debbugs.gnu.org
Subject: disk-image fails to install efi grub
Date: Tue, 23 Apr 2019 01:06:15 +0900

Package: guix
Version: 0.16.0

This might be 2 bugs.

I ran `guix pull` a few hours ago.

I have a minimal system configuration:
```
(use-modules (gnu))
(operating-system
    (host-name "min1")
    (timezone "UTC")
    (locale "en_US.utf8")
    (bootloader (bootloader-configuration
        (bootloader grub-bootloader)
    ))
    (file-systems (cons
        (file-system
            (device (file-system-label "abcdefghijk"))
            (mount-point "/")
            (type "ext4"))
        %base-file-systems))
)
```

This boots fine with:
```
qemu-system-x86_64 -m 1024 testimage
```
(after copying to testimage and doing chmod u+w)

Changing it to use grub-efi-bootloader results in this error during build:
```
installing bootloader...
/gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/sbin/grub-install:
error:
/gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/lib/grub/i386-pc/modinfo.sh
doesn't exist. Please spe.
Backtrace:
           2 (primitive-load "/gnu/store/mkbilylx3l6c2y9pdckdiibcpwb?")
In ./gnu/build/vm.scm:
    534:6  1 (initialize-hard-disk "/dev/vda" #:bootloader-package _ ?)
In unknown file:
           0 (scm-error misc-error #f "~A" ("failed to install GRU?") ?)

ERROR: In procedure scm-error:
failed to install GRUB (EFI)
boot program
'/gnu/store/0m2ap3d4c9gl7chmsrh7ci7i5gy4bbl0-linux-vm-loader'
terminated, rebooting
[  184.005459] Unregister pv shared memory for cpu 0
[  184.006818] reboot: Restarting system
[  184.007498] reboot: machine restart
successfully built
/gnu/store/57smyxccd3965dzirpcjfdkljbv9mrpy-disk-image.drv
/gnu/store/f90acaac9wvg61i6j3mgjfjvyd5p1yzg-disk-image
```

Bug 1: Even though there's a fairly serious error (bootloader failed to
install) a broken image is produced and it exits with a success status code.

Running with the same command above, qemu halts saying the drive isn't
bootable, trying floppy disks, etc.

Bug 2: So is it appears disk-image won't build with an EFI bootloader.
I'm guessing that qemu is run with a bios boot image here, which is why
grub's using i386-pc.

I'm building the image for a UEFI machine and I don't want to disable
UEFI so this is a blocker.

Message #8 received at 35380 <at> debbugs.gnu.org (full text, mbox):

From: rendaw <7e9wc56emjakcm <at> s.rendaw.me>
To: 35380 <at> debbugs.gnu.org
Subject: Re: bug#35380: Acknowledgement (disk-image fails to install efi grub)
Date: Tue, 23 Apr 2019 02:11:09 +0900

On 4/23/19 1:07 AM, GNU bug Tracking System wrote:
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix <at> gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 35380 <at> debbugs.gnu.org.
>
> Please do not send mail to help-debbugs <at> gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>

I ran guix pull and rebuilt the image, and now see this error:

```

installing bootloader...
Backtrace:
           1 (primitive-load "/gnu/store/chp5kal8skdfnz8p4xcr9v5x80p?")
In ./gnu/build/vm.scm:
    552:6  0 (initialize-hard-disk "/dev/vda" #:bootloader-package _ ?)

./gnu/build/vm.scm:552:6: In procedure initialize-hard-disk:
Throw to key `srfi-34' with args `(#<condition &message [message:
"'/gnu/store/c3dj2q7x99xgnmskvpzjg97m3yhv6k8m-grub-efi-2.02/sbin/grub-install
--boot-directory /fs/boot --bootloader-id=Guix --ef.
[  110.993072] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100
[  110.993949] CPU: 0 PID: 163 Comm: init Not tainted 5.0.9-gnu #1
[  110.994631] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
[  110.995921] Call Trace:
[  110.996216]  dump_stack+0x63/0x8d
[  110.996608]  panic+0xfe/0x2a4
[  110.996918]  do_exit+0xba1/0xbb0
[  110.997256]  do_group_exit+0x44/0xb0
[  110.997622]  get_signal+0x134/0x6d0
[  110.997981]  ? __vfs_read+0x192/0x210
[  110.998356]  do_signal+0x4e/0x710
[  110.998698]  exit_to_usermode_loop+0x7c/0xf0
[  110.999132]  do_syscall_64+0x101/0x120
[  110.999517]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  111.000075] RIP: 0033:0x4bac5c
[  111.000360] Code: Bad RIP value.
[  111.000676] RSP: 002b:00007f20f6eb6ec0 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[  111.001432] RAX: fffffffffffffe00 RBX: 000000000000000c RCX:
00000000004bac5c
[  111.002145] RDX: 0000000000000001 RSI: 00007f20f6eb7390 RDI:
000000000000000c
[  111.002901] RBP: 00007f20f6eb7390 R08: 0000000000000000 R09:
00007f20f8573f38
[  111.003621] R10: 0000000000000008 R11: 0000000000000246 R12:
0000000000000001
[  111.004339] R13: 0000000000000002 R14: 0000000000000002 R15:
000000000000000a
[  111.005684] Kernel Offset: 0x1a000000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  111.006752] Rebooting in 1 seconds..
successfully built
/gnu/store/63r04mvsk05wrx5hd9langkp9wfkxr05-disk-image.drv
/gnu/store/jygpabbgp34y0p68qcv4v515fabmd1hv-disk-image
```

I'm not sure if it's the same issue, or if the kernel panic is related,
but since the error mentions `grub-install` I think it's likely the same.

Message #13 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: rendaw <7e9wc56emjakcm <at> s.rendaw.me>
Cc: 35380-done <at> debbugs.gnu.org
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Thu, 25 Apr 2019 10:44:29 +0200

Hi rendaw,

rendaw <7e9wc56emjakcm <at> s.rendaw.me> skribis:

> Bug 2: So is it appears disk-image won't build with an EFI bootloader.
> I'm guessing that qemu is run with a bios boot image here, which is why
> grub's using i386-pc.

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’.

Message #16 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: rendaw <7e9wc56emjakcm <at> s.rendaw.me>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 35380-done <at> debbugs.gnu.org
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Thu, 25 Apr 2019 19:27:14 +0900

On 4/25/19 5:44 PM, Ludovic Courtès wrote:
> Hi rendaw,
>
> rendaw <7e9wc56emjakcm <at> s.rendaw.me> skribis:
>
>> Bug 2: So is it appears disk-image won't build with an EFI bootloader.
>> I'm guessing that qemu is run with a bios boot image here, which is why
>> grub's using i386-pc.
> 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. 

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

Message #19 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: rendaw <7e9wc56emjakcm <at> s.rendaw.me>
Cc: 35380-done <at> debbugs.gnu.org
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Wed, 01 May 2019 22:19:58 +0200

Hi rendaw,

rendaw <7e9wc56emjakcm <at> 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.

> 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’.

Message #22 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: Gábor Boskovits <boskovits <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 35380-done <at> debbugs.gnu.org, rendaw <7e9wc56emjakcm <at> s.rendaw.me>
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Thu, 2 May 2019 11:05:00 +0200

[Message part 1 (text/plain, inline)]

Hello,

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

> Hi rendaw,
>
> rendaw <7e9wc56emjakcm <at> 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

[Message part 2 (text/html, inline)]

Message #25 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Gábor Boskovits <boskovits <at> gmail.com>
Cc: 35380-done <at> debbugs.gnu.org, Marius Bakke <mbakke <at> fastmail.com>,
 rendaw <7e9wc56emjakcm <at> s.rendaw.me>
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Thu, 02 May 2019 17:16:52 +0200

Hello,

Gábor Boskovits <boskovits <at> 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?

I’m not familiar with all this.  ISTR that Marius looked into it back
then, so perhaps there are ideas to share?

Thanks,
Ludo’.

Message #28 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, Gábor
 Boskovits <boskovits <at> gmail.com>
Cc: 35380-done <at> debbugs.gnu.org, rendaw <7e9wc56emjakcm <at> s.rendaw.me>
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Fri, 03 May 2019 00:17:53 +0200

[Message part 1 (text/plain, inline)]

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

> Hello,
>
> Gábor Boskovits <boskovits <at> 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 :-)

[signature.asc (application/pgp-signature, inline)]

Message #31 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: rendaw <7e9wc56emjakcm <at> s.rendaw.me>
To: Marius Bakke <mbakke <at> fastmail.com>, Ludovic Courtès
 <ludo <at> gnu.org>, Gábor Boskovits <boskovits <at> gmail.com>
Cc: 35380-done <at> debbugs.gnu.org
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Fri, 3 May 2019 22:18:01 +0900

On 5/3/19 7:17 AM, Marius Bakke wrote:
> 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 :-)

Yeah, ideally I'd like secure boot from the flashed media but failing
that I'd at least like to be moving closer to it (boot without having to
enable legacy boot).

> That means you can't just take an operating system hard drive from one
> EFI system to another.

I'm absolutely not an expert on UEFI, and it's likely I'm
misinterpreting some of the more subtle points you wrote, but do you
have more information on the NVRAM restriction?  I've found a fair
amount of references to making secure boot and UEFI capable media (USB
and CD) around the web so I'm surprised it's not possible to make a
portable UEFI image.  Wouldn't that make it difficult to install UEFI
bootloaders on blank systems?

Message #34 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: rendaw <7e9wc56emjakcm <at> s.rendaw.me>, Ludovic Courtès
 <ludo <at> gnu.org>, Gábor Boskovits <boskovits <at> gmail.com>
Cc: 35380-done <at> debbugs.gnu.org
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Fri, 03 May 2019 17:10:29 +0200

[Message part 1 (text/plain, inline)]

rendaw <7e9wc56emjakcm <at> s.rendaw.me> writes:

> On 5/3/19 7:17 AM, Marius Bakke wrote:
>> 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 :-)
>
> Yeah, ideally I'd like secure boot from the flashed media but failing
> that I'd at least like to be moving closer to it (boot without having to
> enable legacy boot).

I see.  Do you know what is needed to enable secure boot with grub-efi?

>> That means you can't just take an operating system hard drive from one
>> EFI system to another.
>
> I'm absolutely not an expert on UEFI, and it's likely I'm
> misinterpreting some of the more subtle points you wrote, but do you
> have more information on the NVRAM restriction?  I've found a fair
> amount of references to making secure boot and UEFI capable media (USB
> and CD) around the web so I'm surprised it's not possible to make a
> portable UEFI image.  Wouldn't that make it difficult to install UEFI
> bootloaders on blank systems?

To clarify: "grub-efi" will not work to make a portable UEFI
installation.  For that you need "grub-mkstandalone" and place the
resulting executable in "/efi/boot/bootx64.efi" on your EFI System
Partition, like Guix does for disk images:
<https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/vm.scm#n399>.

It would be nice to make this procedure more generally accessible.
Perhaps create a (grub-standalone-bootloader ...) procedure, similar to
(grub-efi-bootloader)?   Then it can be used to create portable EFI
systems straight from your config.scm.

Would you like to give it a go?

[signature.asc (application/pgp-signature, inline)]

Message #37 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: rendaw <7e9wc56emjakcm <at> s.rendaw.me>
To: Marius Bakke <mbakke <at> fastmail.com>, Ludovic Courtès
 <ludo <at> gnu.org>, Gábor Boskovits <boskovits <at> gmail.com>
Cc: 35380-done <at> debbugs.gnu.org
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Sat, 4 May 2019 12:42:39 +0900

On 5/4/19 12:10 AM, Marius Bakke wrote:
> rendaw <7e9wc56emjakcm <at> s.rendaw.me> writes:
>
>> On 5/3/19 7:17 AM, Marius Bakke wrote:
>>> 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 :-)
>> Yeah, ideally I'd like secure boot from the flashed media but failing
>> that I'd at least like to be moving closer to it (boot without having to
>> enable legacy boot).
> I see.  Do you know what is needed to enable secure boot with grub-efi?
So having read your clarification below, I assume this question is about
grub-efi specifically.  I might have been overly specific with my
original report but I would like to boot (uefi with or without secure
boot) with any boot loader, not necessarily grub-efi.  I have no idea
how this is done with grub-efi specifically - some Ubuntu docs suggest
that they use a Microsoft-signed shim loader that operates before grub-efi.
>>> That means you can't just take an operating system hard drive from one
>>> EFI system to another.
>> I'm absolutely not an expert on UEFI, and it's likely I'm
>> misinterpreting some of the more subtle points you wrote, but do you
>> have more information on the NVRAM restriction?  I've found a fair
>> amount of references to making secure boot and UEFI capable media (USB
>> and CD) around the web so I'm surprised it's not possible to make a
>> portable UEFI image.  Wouldn't that make it difficult to install UEFI
>> bootloaders on blank systems?
> To clarify: "grub-efi" will not work to make a portable UEFI
> installation.  For that you need "grub-mkstandalone" and place the
> resulting executable in "/efi/boot/bootx64.efi" on your EFI System
> Partition, like Guix does for disk images:
> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/vm.scm#n399>.
>
> It would be nice to make this procedure more generally accessible.
> Perhaps create a (grub-standalone-bootloader ...) procedure, similar to
> (grub-efi-bootloader)?   Then it can be used to create portable EFI
> systems straight from your config.scm.
>
> Would you like to give it a go?
Ah thanks!  I was indeed misunderstanding some of the subtleties in your
previous post, and thanks for the pointers.  Depending on how
straightforward it is I might try my hand implementing it, time
permitting, but it probably wouldn't be for at least a month due to
other priorities.

Message #40 received at 35380-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: rendaw <7e9wc56emjakcm <at> s.rendaw.me>, Ludovic Courtès
 <ludo <at> gnu.org>, Gábor Boskovits <boskovits <at> gmail.com>
Cc: 35380-done <at> debbugs.gnu.org
Subject: Re: bug#35380: disk-image fails to install efi grub
Date: Sat, 04 May 2019 16:34:55 +0200

[Message part 1 (text/plain, inline)]

rendaw <7e9wc56emjakcm <at> s.rendaw.me> writes:

> On 5/4/19 12:10 AM, Marius Bakke wrote:
>> rendaw <7e9wc56emjakcm <at> s.rendaw.me> writes:
>>
>>> On 5/3/19 7:17 AM, Marius Bakke wrote:
>>>> That means you can't just take an operating system hard drive from one
>>>> EFI system to another.
>>> I'm absolutely not an expert on UEFI, and it's likely I'm
>>> misinterpreting some of the more subtle points you wrote, but do you
>>> have more information on the NVRAM restriction?  I've found a fair
>>> amount of references to making secure boot and UEFI capable media (USB
>>> and CD) around the web so I'm surprised it's not possible to make a
>>> portable UEFI image.  Wouldn't that make it difficult to install UEFI
>>> bootloaders on blank systems?
>> To clarify: "grub-efi" will not work to make a portable UEFI
>> installation.  For that you need "grub-mkstandalone" and place the
>> resulting executable in "/efi/boot/bootx64.efi" on your EFI System
>> Partition, like Guix does for disk images:
>> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/vm.scm#n399>.
>>
>> It would be nice to make this procedure more generally accessible.
>> Perhaps create a (grub-standalone-bootloader ...) procedure, similar to
>> (grub-efi-bootloader)?   Then it can be used to create portable EFI
>> systems straight from your config.scm.
>>
>> Would you like to give it a go?
> Ah thanks!  I was indeed misunderstanding some of the subtleties in your
> previous post, and thanks for the pointers.  Depending on how
> straightforward it is I might try my hand implementing it, time
> permitting, but it probably wouldn't be for at least a month due to
> other priorities.

Right, no worries!  Improving the EFI support in Guix has been on my
TODO list for a couple of years now, so it's not very urgent ;-)

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.