I'm told rebooting is sometimes unreliable when called here, and we'll
get bootx64.efi loaded anyway. I'll just assume that's true and try to
load the first option, since it's clearly what we'd prefer happens next.
Signed-off-by: Peter Jones <pjones@redhat.com>
I'm told rebooting is sometimes unreliable when called here, and we'll
get bootx64.efi loaded anyway. I'll just assume that's true and try to
load the first option, since it's clearly what we'd prefer happens next.
Signed-off-by: Peter Jones <pjones@redhat.com>
If shim is invoked as \EFI\BOOT\BOOT*.EFI and a file exists named
\EFI\BOOT\FALLBACK.EFI, try it instead of our second stage. So don't
put fallback.efi on your install media in \EFI\BOOT, because that won't
do whatever it is you're hoping for, unless you're hoping not to start
the installer.
So here's the process for using this:
in /EFI/fedora/ (or whichever directory you happen to own), you put:
shim.efi
grub.efi
boot.csv - format is: shim.efi,Nice Label,cmdline arguments,comments
- filenames refer only to files in this directory, with no
leading characters such as L"./" or L"/EFI/fedora/"
- note that while this is CSV, the character encoding is
UCS-2
and if /EFI/BOOT/BOOTX64.EFI doesn't already exist, then in /EFI/BOOT:
shim.efi as BOOTX64.EFI
fallback.efi
Signed-off-by: Peter Jones <pjones@redhat.com>
If shim is invoked as \EFI\BOOT\BOOT*.EFI and a file exists named
\EFI\BOOT\FALLBACK.EFI, try it instead of our second stage. So don't
put fallback.efi on your install media in \EFI\BOOT, because that won't
do whatever it is you're hoping for, unless you're hoping not to start
the installer.
So here's the process for using this:
in /EFI/fedora/ (or whichever directory you happen to own), you put:
shim.efi
grub.efi
boot.csv - format is: shim.efi,Nice Label,cmdline arguments,comments
- filenames refer only to files in this directory, with no
leading characters such as L"./" or L"/EFI/fedora/"
- note that while this is CSV, the character encoding is
UCS-2
and if /EFI/BOOT/BOOTX64.EFI doesn't already exist, then in /EFI/BOOT:
shim.efi as BOOTX64.EFI
fallback.efi
Signed-off-by: Peter Jones <pjones@redhat.com>
The previous commit, 14d4b8e, caused shim failed to parse the name
of the 2nd stage loader in UEFI shell. Amend parsing of the name the
2nd stage loader to be compatible with UEFI shell.
To create an boot entry for elilo.efi:
# efibootmgr -c -L "shim elilo" -l "efi\\shim.efi" -u "shim.efi elilo.efi"
The previous commit, 14d4b8e, caused shim failed to parse the name
of the 2nd stage loader in UEFI shell. Amend parsing of the name the
2nd stage loader to be compatible with UEFI shell.
To create an boot entry for elilo.efi:
# efibootmgr -c -L "shim elilo" -l "efi\\shim.efi" -u "shim.efi elilo.efi"
Sometimes when we're creating paths, the ImagePath can contain the
directory name already. If that happens, don't add it in again.
Signed-off-by: Peter Jones <pjones@redhat.com>
Sometimes when we're creating paths, the ImagePath can contain the
directory name already. If that happens, don't add it in again.
Signed-off-by: Peter Jones <pjones@redhat.com>
If li->LoadOptions tells us to execute our own binary, it's clearly not
what we want to do for the second stage. So simply ignore that case.
Signed-off-by: Peter Jones <pjones@redhat.com>
If li->LoadOptions tells us to execute our own binary, it's clearly not
what we want to do for the second stage. So simply ignore that case.
Signed-off-by: Peter Jones <pjones@redhat.com>
Since Pause() doesn't clear the key from the input queue, the next
ReadKeyStroke reads the queued key instead of the new one. If the
user presses "Enter", MokManager exits directly without showing
the menu again.
Since Pause() doesn't clear the key from the input queue, the next
ReadKeyStroke reads the queued key instead of the new one. If the
user presses "Enter", MokManager exits directly without showing
the menu again.
