Mailinglist Archive: opensuse-bugs (4250 mails)

< Previous Next >
[Bug 1018741] after Xen 4.7 -> 4.8 upgrade, Xen PVHVM/UEFI guests fail to boot; hang @~ OVMF
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 11 Jan 2017 03:19:28 +0000
  • Message-id: <bug-1018741-21960-JfKlv2euNK@http.bugzilla.opensuse.org/>
http://bugzilla.opensuse.org/show_bug.cgi?id=1018741
http://bugzilla.opensuse.org/show_bug.cgi?id=1018741#c26

Gary Ching-Pang Lin <glin@xxxxxxxx> changed:

What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(glin@xxxxxxxx) |

--- Comment #26 from Gary Ching-Pang Lin <glin@xxxxxxxx> ---
(In reply to lists dev from comment #21)
(In reply to Gary Ching-Pang Lin from comment #20)
To simplify the boot path, openSUSE always boots from shim.efi. shim.efi
will detect the SecureBoot variable and decide whether the signature
verification should be applied or not.

IIUC, the use of /boot/efi/startup.nsh, which here contains:

echo "fs0:\EFI\opensuse\grubx64.efi" > /boot/efi/startup.nsh

is supposed to simplify the boot path.

opensuse ignores the presence/use of it?
No, it's not relevant to the boot path.

For UEFI, the priority of the boot loader is decided by BDS in the firmware.
For OS, after installation, it should create a boot option and set the priority
of the boot option, and then BDS chooses one boot option from the existed ones.
To simplify the boot path, openSUSE only creates one boot option which points
to shim.efi instead of creating another one for grub.efi.

startup.nsh is for UEFI shell, and it only works when BDS boots UEFI shell.

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