Mailinglist Archive: opensuse-bugs (3349 mails)

< Previous Next >
[Bug 978593] EFI fails to load up the grub2 image erroring out on snapshot path
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Fri, 06 May 2016 11:18:01 +0000
  • Message-id: <bug-978593-21960-WSmWHTHiYJ@http.bugzilla.suse.com/>
http://bugzilla.suse.com/show_bug.cgi?id=978593
http://bugzilla.suse.com/show_bug.cgi?id=978593#c18

--- Comment #18 from Michael Chang <mchang@xxxxxxxx> ---
(In reply to Alexander Graf from comment #16)
(In reply to Michael Chang from comment #15)

Why? Wouldn't the "normal" EFI systems covered by that check as well ? (ie
it will not append --no-nvram --removable)

Exactly, so for the "normal" systems nothing changes over today's state. We
still have a broken removable file because pbl installed it, so if we end up
in the fallback case for whatever reason (nvram invalidated in between
executions, wrong boot order configured manually, etc) we still boot the
wrong one.

Maybe as a temporary fix we should check for ARM patform in that pbl patch (or
even yast in the future), we should leave that default efi loader in x86
hanldled by shim's fallback mode (ie shim-install).

It's even more hard to say as an analogy to mbr whether we should "update" that
file or not from our system. It maybe owned by other distro, much more likely
on x86.. It should really be an option for x86 but I think ARM is fine with
that.


In my case, I usually end up with the removable fallback because I use
qemu's -bios option which treats all nvram variables as volatile, so after a
reset they're gone.

The vars are store in ESP, IIRC, as file name /NvVars to be restore during OVMF
booting. But that's a hack indeed. (And I don't know whether it's also the case
for ARM).

--
You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >
References