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:36:55 +0000
  • Message-id: <bug-978593-21960-oWjvHMd0l4@http.bugzilla.suse.com/>
http://bugzilla.suse.com/show_bug.cgi?id=978593
http://bugzilla.suse.com/show_bug.cgi?id=978593#c19

--- Comment #19 from Alexander Graf <agraf@xxxxxxxx> ---
(In reply to Michael Chang from comment #18)
(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).

I think if what you say is true, the best solution would be to just include
efivars.ko in the installer system. Then the rest should resolve itself
automatically, because we will detect the correct type of system again.

Also, whether we use shim or grub2-install is completely orthogonal over
whether we want to install the bootloader as --removable or not. Shim vs
grub2-install is a software concept, NVRAM available or not is a hardware
problem - some systems simply don't have any storage for it.

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

Hm, if it's intended to work, it definitely did not work for me :).

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