If we don't have writable grubenv and we're on EFI, always show the menu
If we don't have writable grubenv, recordfail doesn't work, which means our
quickboot behavior - with a timeout of 0 - leaves the user without a
reliable way to access the boot menu if they're on UEFI, because unlike
BIOS, UEFI does not support checking the state of modifier keys (i.e.
holding down shift at boot is not detectable).
Handle this corner case by always using a non-zero timeout on EFI when
save_env doesn't work.
Reuse GRUB_RECORDFAIL_TIMEOUT to avoid introducing another variable.
* debian/patches/grub-install-extra-removable.patch: install mmx64.efi to
the EFI removable path to avoid boot failures after install when certs
need to be enrolled and the system's firmware is confused. (LP: #1798171)
After hexdumping "bootmgfw.efi" and manually walking its relocation blocks
(yes, really), I determined that the (smaller) RelocDir value is correct.
The remaining area that extends up to the .reloc section size (== 0xe22 -
0x574 == 0x8ae bytes) exists as zero padding in the file.
This zero padding shouldn't be passed to relocate_coff() for parsing. In
order to cope with it, split the handling of .reloc sections into the
following branches:
- original case (equal size): original behavior (--> relocation
attempted),
- overlong .reloc section (longer than reported by RelocDir): truncate the
section to the RelocDir size for the purposes of relocate_coff(), and
attempt relocation,
- .reloc section is too short, or other checks fail: original behavior
(--> relocation not attempted).
efi/chainloader: fix wrong sanity check in relocate_coff()
In relocate_coff(), the relocation entries are parsed from the original
image (not the section-wise copied image). The original image is
pointed-to by the "orig" pointer. The current check
(void *)reloc_end < data
compares the addresses of independent memory allocations. "data" is a typo
here, it should be "orig".
grub-reboot: Warn when "for the next boot only" promise cannot be kept
The "for the next boot only" property of grub-reboot is dependent upon
GRUB being able to clear the next_entry variable in the environment
block. However, GRUB cannot write to devices using the diskfilter
and lvm abstractions.
The EFI Graphics Output Protocol can return a 64-bit
linear frame buffer address in some firmware/BIOS
implementations. We currently only store the lower
32-bits in the lfb_base. This will eventually be
passed to Linux kernel and the efifb driver will
incorrectly interpret the framebuffer address as
32-bit address.
The Linux kernel has already added support to handle
64-bit linear framebuffer address in the efifb driver
since quite some time now.
This patch adds the support for 64-bit linear frame
buffer address in GRUB to address the above mentioned
scenario.
Code later on checks if variables inside the struct are
0 to see if they have been set, like if there were addresses
in the bootpath.
The variables were not initialized however, so the check
might suceed with uninitialized data, and a new interface
with random addresses has been added. This caused a weird
bug in Ubuntu, because when booting from network, we now
had two interfaces with the same name, and net_default_mac
pointed to the random one.