Package: grub2 / 2.14~git20250718.0e36779-1
Metadata
| Package | Version | Patches format | 
|---|---|---|
| grub2 | 2.14~git20250718.0e36779-1 | 3.0 (quilt) | 
Patch series
view the series file| Patch | File delta | Description | 
|---|---|---|
| core in fs.patch | (download) | 
              util/setup.c |
                    8 	8 +	0 -	0 ! | write marker if core.img was written to filesystem The Debian bug reporting script includes a warning in this case. Patch-Name: core-in-fs.patch | 
| disable floppies.patch | (download) | 
              grub-core/kern/emu/hostdisk.c |
                   12 	12 +	0 -	0 ! | disable use of floppy devices An ugly kludge. Should this be merged upstream? | 
| gfxpayload keep default.patch | (download) | 
              util/grub.d/10_linux.in |
                    4 	0 +	4 -	0 ! | disable gfxpayload=keep by default Setting gfxpayload=keep has been known to cause efifb to be inappropriately enabled. In any case, with the current Linux kernel the result of this option is that early kernelspace will be unable to print anything to the console, so (for example) if boot fails and you end up dumped to an initramfs prompt, you won't be able to see anything on the screen. As such it shouldn't be enabled by default in Debian, no matter what kernel options are enabled. gfxpayload=keep is a good idea but rather ahead of its time ... Bug-Debian: http://bugs.debian.org/567245 | 
| restore mkdevicemap.patch | (download) | 
              Makefile.util.def |
                   17 	17 +	0 -	0 ! | restore grub-mkdevicemap This is kind of a mess, requiring lots of OS-specific code to iterate over all possible devices. However, we use it in a number of scripts to discover devices and reimplementing those in terms of something else would be very complicated. | 
| gettext quiet.patch | (download) | 
              grub-core/gettext/gettext.c |
                    5 	5 +	0 -	0 ! | silence error messages when translations are unavailable Bug: https://savannah.gnu.org/bugs/?35880 | 
| install efi fallback.patch | (download) | 
              grub-core/osdep/linux/platform.c |
                   40 	35 +	5 -	0 ! | fall back to non-efi if booted using efi but -efi is missing It may be possible, particularly in recovery situations, to be booted using EFI on x86 when only the i386-pc target is installed, or on ARM when only the arm-uboot target is installed. There's nothing actually stopping us installing i386-pc or arm-uboot from an EFI environment, and it's better than returning a confusing error. | 
| mkconfig ubuntu recovery.patch | (download) | 
              configure.ac |
                   11 	11 +	0 -	0 ! | "single" -> "recovery" when friendly-recovery is installed MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit If configured with --enable-ubuntu-recovery, also set nomodeset for recovery mode, and disable 'set gfxpayload=keep' even if the system normally supports it. See https://launchpad.net/ubuntu/+spec/desktop-o-xorg-tools-and-processes. | 
| install locale langpack.patch | (download) | 
              util/grub-install-common.c |
                   37 	30 +	7 -	0 ! | prefer translations from ubuntu language packs if available Bug-Ubuntu: https://bugs.launchpad.net/bugs/537998 | 
| default grub d.patch | (download) | 
              grub-core/osdep/unix/config.c |
                  128 	107 +	21 -	0 ! | read /etc/default/grub.d/*.cfg after /etc/default/grub Bug-Ubuntu: https://bugs.launchpad.net/bugs/901600 | 
| mkconfig distributor.patch | (download) | 
              util/grub.d/10_linux.in |
                    9 	8 +	1 -	0 ! | don't add suffix to the distributor string - Ubuntu is called "Ubuntu", not "Ubuntu GNU/Linux" - Debian already has the suffix in `/etc/os-release` | 
| maybe quiet.patch | (download) | 
              config.h.in |
                    2 	2 +	0 -	0 ! | add configure option to reduce visual clutter at boot time If this option is enabled, then do all of the following: Don't display introductory message about line editing unless we're actually offering a shell prompt. (This is believed to be a workaround | 
| quick boot.patch | (download) | 
              configure.ac |
                   11 	11 +	0 -	0 ! | add configure option to bypass boot menu if possible If other operating systems are installed, then automatically unhide the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus if available to check whether Shift is pressed. If it is, show the menu, otherwise boot immediately. If keystatus is not available, then fall back to a short delay interruptible with Escape. This may or may not remain Ubuntu-specific, although it's not obviously wanted upstream. It implements a requirement of https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader. If the previous boot failed (defined as failing to get to the end of one of the normal runlevels), then show the boot menu regardless. | 
| quick boot lvm.patch | (download) | 
              util/grub.d/00_header.in |
                   18 	15 +	3 -	0 ! | 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. Signed-off-by: Steve Langasek <steve.langasek@canonical.com> Bug-Ubuntu: https://bugs.launchpad.net/bugs/1800722 | 
| gfxpayload dynamic.patch | (download) | 
              configure.ac |
                   11 	11 +	0 -	0 ! | add configure option to enable gfxpayload=keep dynamically Set GRUB_GFXPAYLOAD_LINUX=keep unless it's known to be unsupported on the current hardware. See https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-grub2-boot-framebuffer. | 
| vt handoff.patch | (download) | 
              configure.ac |
                   11 	11 +	0 -	0 ! | add configure option to use vt.handoff=7 This is used for non-recovery Linux entries only; it enables flicker-free booting if gfxpayload=keep is in use and a suitable kernel is present. | 
| probe fusionio.patch | (download) | 
              grub-core/osdep/linux/getroot.c |
                   13 	13 +	0 -	0 ! | probe fusionio devices Bug-Ubuntu: https://bugs.launchpad.net/bugs/1237519 | 
| mkconfig recovery title.patch | (download) | 
              docs/grub.texi |
                    5 	5 +	0 -	0 ! | add grub_recovery_title option This allows the controversial "recovery mode" text to be customised. Bug-Ubuntu: https://bugs.launchpad.net/bugs/1240360 | 
| install powerpc machtypes.patch | (download) | 
              grub-core/osdep/basic/platform.c |
                    5 	5 +	0 -	0 ! | port yaboot logic for various powerpc machine types Some powerpc machines require not updating the NVRAM. This can be handled by existing grub-install command-line options, but it's friendlier to detect this automatically. On chrp_ibm machines, use the nvram utility rather than nvsetenv. (This is possibly suitable for other machines too, but that needs to be verified.) | 
| ieee1275 clear reset.patch | (download) | 
              grub-core/term/terminfo.c |
                    2 	1 +	1 -	0 ! | include a text attribute reset in the clear command for ppc Always clear text attribute for clear command in order to avoid problems after it boots. * grub-core/term/terminfo.c: Add escape for text attribute reset Bug-Ubuntu: https://bugs.launchpad.net/bugs/1295255 | 
| ppc64el disable vsx.patch | (download) | 
              grub-core/kern/powerpc/ieee1275/startup.S |
                   12 	12 +	0 -	0 ! | disable vsx instruction VSX bit is enabled by default for Power7 and Power8 CPU models, so we need to disable them in order to avoid instruction exceptions. Kernel will activate it when necessary. * grub-core/kern/powerpc/ieee1275/startup.S: Disable VSX. Also-By: Adhemerval Zanella <azanella@linux.vnet.ibm.com> Also-By: Colin Watson <cjwatson@debian.org> | 
| grub install pvxen paths.patch | (download) | 
              util/grub-install.c |
                   24 	22 +	2 -	0 ! | grub-install: install pv xen binaries into the upstream specified path Upstream have defined a specification for where guests ought to place their xenpv grub binaries in order to facilitate chainloading from a stage 1 grub loaded from dom0. http://xenbits.xen.org/docs/unstable-staging/misc/x86-xenpv-bootloader.html The spec calls for installation into /boot/xen/pvboot-i386.elf or /boot/xen/pvboot-x86_64.elf. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Bug-Debian: https://bugs.debian.org/762307 | 
| insmod xzio and lzopio on xen.patch | (download) | 
              util/grub.d/10_linux.in |
                    1 	1 +	0 -	0 ! | arrange to insmod xzio and lzopio when booting a kernel as a xen guest This is needed in case the Linux kernel is compiled with CONFIG_KERNEL_XZ or CONFIG_KERNEL_LZO rather than CONFIG_KERNEL_GZ (gzio is already loaded by grub.cfg today). Signed-off-by: Ian Campbell <ijc@debian.org> Bug-Debian: https://bugs.debian.org/755256 | 
| zpool full device name.patch | (download) | 
              grub-core/osdep/unix/getroot.c |
                    1 	1 +	0 -	0 ! | tell zpool to emit full device names zfs-initramfs currently provides extraneous, undesired symlinks to devices directly underneath /dev/ to satisfy zpool's historical output of unqualified device names. By including this environment variable to signal our intent to zpool, zfs-linux packages can drop the symlink behavior when updating to its upstream or backported output behavior. Bug: https://savannah.gnu.org/bugs/?43653 Bug-Debian: https://bugs.debian.org/824974 Bug-Ubuntu: https://bugs.launchpad.net/bugs/1527727 | 
| network/net http check result of grub_netbuff_put in http_receive.patch | (download) | 
              grub-core/net/http.c |
                    4 	3 +	1 -	0 ! | net/http: check result of grub_netbuff_put() in http_receive() Co-authored-by: Peter Jones <pjones@redhat.com> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/bootp new net_bootp6 command.patch | (download) | 
              grub-core/net/bootp.c |
                  910 	909 +	1 -	0 ! | efinet + bootp: add net_bootp6 command supporting dhcpv6 Implement new net_bootp6 command for IPv6 network auto configuration via the DHCPv6 protocol (RFC3315). Signed-off-by: Peter Jones <pjones@redhat.com> Co-authored-by: Michael Chang <mchang@suse.com> Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Ken Lin <ken.lin@hpe.com> Co-authored-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/efinet add structures for PXE messages.patch | (download) | 
              grub-core/net/drivers/efi/efinet.c |
                    2 	2 +	0 -	0 ! | efinet: add structures for pxe messages When grub2 image is booted from UEFI IPv6 PXE, the DHCPv6 Reply packet is cached in firmware buffer which can be obtained by PXE Base Code protocol. The network interface can be setup through the parameters in that obtained packet. Augment existing structures to represent this, and make them agnostic between ipv4 and ipv6. Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Ken Lin <ken.lin@hpe.com> Co-authored-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/bootp process dhcpack http boot.patch | (download) | 
              grub-core/net/bootp.c |
                   55 	55 +	0 -	0 ! | bootp: process dhcpack packet during http boot The vendor class identifier with the string "HTTPClient" is used to denote the packet as responding to HTTP boot request. In DHCP4 config, the filename for HTTP boot is the URL of the boot file, while for PXE boot it is the path to the boot file. As a consequence, the next-server becomes obselete because the HTTP URL already contains the server | 
| network/efinet Configure network from UEFI device path.patch | (download) | 
              grub-core/net/drivers/efi/efinet.c |
                  278 	263 +	15 -	0 ! |  efinet configure network from uefi device path
The PXE Base Code protocol used to obtain cached PXE DHCPACK packet is
no longer provided for HTTP Boot.  Instead, we have to get the HTTP boot
information from the device path nodes defined in following UEFI
Specification sections.
    9.3.5.12 IPv4 Device Path
    9.3.5.13 IPv6 Device Path
    9.3.5.23 Uniform Resource Identifiers (URI) Device Path
This patch basically does:
include/grub/efi/api.h:
Add new structure for Uniform Resource Identifiers (URI) Device Path
grub-core/net/drivers/efi/efinet.c:
Check if PXE Base Code is available.  If not, try to obtain the netboot
information from the device path where the image booted from.  The
DHCPACK packet is recoverd from the information in device patch and fed
into the same DHCP packet processing functions to ensure the network
interface is set up the same way it used to be.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Ken Lin <ken.lin@hpe.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
 | 
| network/efinet set dns from uefi proto.patch | (download) | 
              grub-core/net/drivers/efi/efinet.c |
                  160 	160 +	0 -	0 ! |  efinet: set dns server from uefi protocol
In the URI device path node, any name rather than address can be used
for looking up the resources so that DNS service become needed to get
answer of the name's address.  Unfortunately, DNS is not defined in any
of the device path nodes so that we use the EFI_IP4_CONFIG2_PROTOCOL and
EFI_IP6_CONFIG_PROTOCOL to obtain it.
These two protcols are defined the sections of UEFI specification.
    27.5 EFI IPv4 Configuration II Protocol
    27.7 EFI IPv6 Configuration Protocol
include/grub/efi/api.h:
Add new structure and protocol UUID of EFI_IP4_CONFIG2_PROTOCOL and
EFI_IP6_CONFIG_PROTOCOL.
grub-core/net/drivers/efi/efinet.c:
Use the EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL to obtain
the list of DNS server address for IPv4 and IPv6 respectively.  The
address of DNS servers is structured into DHCPACK packet and feed into
the same DHCP packet processing functions to ensure the network
interface is setting up the same way it used to be.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Ken Lin <ken.lin@hpe.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
(rebased against 2.12)
 | 
| network/support uefi networking protocols.patch | (download) | 
              grub-core/Makefile.core.def |
                    6 	6 +	0 -	0 ! | support uefi networking protocols References: fate#320130, bsc#1015589, bsc#1076132, rhbz#1732765 Co-authored-by: Peter Jones <pjones@redhat.com> Co-authored-by: Sebastian Krahmer <krahmer@suse.com> Co-authored-by: Javier Martinez Canillas <javierm@redhat.com> Co-authored-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/efinet also use the firmware acceleration for http.patch | (download) | 
              grub-core/net/efi/net.c |
                    5 	4 +	1 -	0 ! | efinet: also use the firmware acceleration for http Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/efi http match protocol hostname of boot url in root.patch | (download) | 
              grub-core/net/efi/http.c |
                   19 	19 +	0 -	0 ! | efi/http: match protocol+hostname of boot url in root_url This lets you write config files that don't know urls. Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/add fw_path variable to detect config file on efi.patch | (download) | 
              grub-core/kern/main.c |
                   14 	7 +	7 -	0 ! | add fw_path variable to detect config file on efi This patch makes grub look for its config file on efi where the app was found. Resolves: rhbz#857936, rhbz#1616395 Co-authored-by: Matthew Garrett Co-authored-by: Javier Martinez Canillas <javierm@redhat.com> Co-authored-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@br.ibm.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/use fw_path prefix when fallback searching for grub config.patch | (download) | 
              grub-core/normal/main.c |
                    5 	3 +	2 -	0 ! | use fw_path prefix when fallback searching for grub config When PXE booting via UEFI firmware, grub was searching for grub.cfg in the fw_path directory where the grub application was found. If that didn't exist, a fallback search would look for config file names based on MAC and IP address. However, the search would look in the prefix directory which may not be the same fw_path. This patch changes that behavior to use the fw_path directory for the fallback search. Only if fw_path is NULL will the prefix directory be searched. Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/try prefixes for tftp config file.patch | (download) | 
              grub-core/kern/ieee1275/init.c |
                   28 	15 +	13 -	0 ! | try mac/guid/etc before grub.cfg on tftp config files Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/prepend prefix when http path is relative.patch | (download) | 
              grub-core/kern/main.c |
                   10 	9 +	1 -	0 ! | prepend prefix when http path is relative This sets a couple of variables. With the url http://www.example.com/foo/bar : http_path: /foo/bar http_url: http://www.example.com/foo/bar Resolves: rhbz#1616395 Co-authored-by: Javier Martinez Canillas <javierm@redhat.com> Co-authored-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Stephen Benjamin <stephen@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/efi http enclose literal ipv6 addresses in square br.patch | (download) | 
              grub-core/net/efi/http.c |
                   37 	28 +	9 -	0 ! | efi/http: enclose literal ipv6 addresses in square brackets According to RFC 2732 (https://www.ietf.org/rfc/rfc2732.txt), literal IPv6 addresses must be enclosed in square brackets. But GRUB currently does not do this and is causing HTTP servers to send Bad Request (400) responses. For example, the following is the HTTP stream when fetching a config file: HEAD /EFI/BOOT/grub.cfg HTTP/1.1 Host: 2000:dead:beef:a::1 Accept: */* User-Agent: UefiHttpBoot/1.0 HTTP/1.1 400 Bad Request Date: Thu, 05 Mar 2020 14:46:02 GMT Server: Apache/2.4.41 (Fedora) OpenSSL/1.1.1d Connection: close Content-Type: text/html; charset=iso-8859-1 and after enclosing the IPv6 address the HTTP request is successful: HEAD /EFI/BOOT/grub.cfg HTTP/1.1 Host: [2000:dead:beef:a::1] Accept: */* User-Agent: UefiHttpBoot/1.0 HTTP/1.1 200 OK Date: Thu, 05 Mar 2020 14:48:04 GMT Server: Apache/2.4.41 (Fedora) OpenSSL/1.1.1d Last-Modified: Thu, 27 Feb 2020 17:45:58 GMT ETag: "206-59f924b24b1da" Accept-Ranges: bytes Content-Length: 518 Resolves: rhbz#1732765 Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/http prepend prefix when the http path is relative.patch | (download) | 
              grub-core/net/http.c |
                   10 	9 +	1 -	0 ! | http: prepend prefix when the http path is relative | 
| network/discover the device to read the config from as fallback.patch | (download) | 
              grub-core/normal/main.c |
                   58 	51 +	7 -	0 ! | normal/main: discover the device to read the config from as a fallback When core.img is generated locally, the grub2-probe tool figures out the device and partition that needs to be read to parse the GRUB configuration file. But in some cases the core.img can't be generated on the host and instead has to be done at package build time. In particular, this will be true when it needs to be signed with a key that's only available on the package building infrastructure. In that case, the prefix variable won't have a device and partition but only a directory path. So there's no way for GRUB to know from which device has to read the configuration file. To allow GRUB to continue working on that scenario, fallback to iterating over all the available devices if reading the config failed when using the prefix and fw_path variables. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Co-authored-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/efinet add dhcp proxy support.patch | (download) | 
              grub-core/net/drivers/efi/efinet.c |
                   27 	25 +	2 -	0 ! | efinet: add dhcp proxy support If a proxyDHCP configuration is used, the server name, server IP and boot file values should be taken from the DHCP proxy offer instead of the DHCP server ack packet. Signed-off-by: Ian Page Hands <iphands@gmail.com> Co-authored-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> | 
| network/rhboot http message field size.patch | (download) | 
              include/grub/efi/http.h |
                    4 	2 +	2 -	0 ! | efi/http: change uint32_t to uintn_t Modify UINT32 to UINTN in EFI_HTTP_MESSAGE to be UEFI 2.9 compliant. Signed-off-by: Keng-Yu Lin <kengyu@hpe.com> Signed-off-by: Nicolas Frayer <nfrayer@redhat.com> Ubuntu-Bug: https://bugs.launchpad.net/bugs/2043084 | 
| skip grub_cmd_set_date.patch | (download) | 
              tests/grub_cmd_set_date.in |
                    3 	3 +	0 -	0 ! | skip flaky grub_cmd_set_date test Bug-Debian: https://bugs.debian.org/906470 | 
| at_keyboard module init.patch | (download) | 
              grub-core/term/at_keyboard.c |
                    9 	9 +	0 -	0 ! | at_keyboard: initialize keyboard in module init if keyboard is ready The change in 0c62a5b2 caused at_keyboard to fail on some machines. Immediately initializing the keyboard in the module init if the keyboard is ready makes the problem go away. Bug-Debian: https://bugs.debian.org/741464 | 
| uefi secure boot cryptomount.patch | (download) | 
              util/grub-install.c |
                   17 	17 +	0 -	0 ! | fix setup on secure boot systems where cryptodisk is in use On full-encrypted systems, including /boot, the current code omits cryptodisk commands needed to open the drives if Secure Boot is enabled. This prevents grub2 from reading any further configuration residing on the encrypted disk. This patch fixes this issue by adding the needed "cryptomount" commands in the load.cfg file that is then copied in the EFI partition. Bug-Debian: https://bugs.debian.org/917117 | 
| efi variable storage minimise writes.patch | (download) | 
              INSTALL |
                    5 	5 +	0 -	0 ! | minimise writes to efi variable storage Some UEFI firmware is easily provoked into running out of space in its variable storage. This is usually due to certain kernel drivers (e.g. pstore), but regardless of the cause it can cause grub-install to fail because it currently asks efibootmgr to delete and re-add entries, and the deletion often doesn't result in an immediate garbage collection. Writing variables frequently also increases wear on the NVRAM which may have limited write cycles. For these reasons, it's desirable to find a way to minimise writes while still allowing grub-install to ensure that a suitable boot entry exists. Unfortunately, efibootmgr doesn't offer an interface that would let grub-install do this. It doesn't in general make very much effort to minimise writes; it doesn't allow modifying an existing Boot* variable entry, except in certain limited ways; and current versions don't have a way to export the expected variable data so that grub-install can compare it to the current data. While it would be possible (and perhaps desirable?) to add at least some of this to efibootmgr, that would still leave the problem that there isn't a good upstreamable way for grub-install to guarantee that it has a new enough version of efibootmgr. In any case, it's cumbersome and slow for grub-install to have to fork efibootmgr to get things done. Fortunately, a few years ago Peter Jones helpfully factored out a substantial part of efibootmgr to the efivar and efiboot libraries, and so it's now possible to have grub-install use those directly. We still have to use some code from efibootmgr, but much less than would previously have been necessary. grub-install now reuses existing boot entries where possible, and avoids writing to variables when the new contents are the same as the old contents. In the common upgrade case where nothing needs to change, it no longer writes to NVRAM at all. It's also now slightly faster, since using libefivar is faster than forking efibootmgr. Fixes Debian bug #891434. Signed-off-by: Colin Watson <cjwatson@ubuntu.com> Bug-Debian: https://bugs.debian.org/891434 | 
| xen no xsm policy in non xsm options.patch | (download) | 
              util/grub.d/20_linux_xen.in |
                    2 	1 +	1 -	0 ! | 20_linux_xen: do not load xsm policy in non-xsm options For complicated reasons, even if you have XSM/FLASK disabled (as is the default) the Xen build system still builds a policy file and puts it in /boot. Even so, we shouldn't be loading this in the usual non-"XSM enabled" entries. It doesn't do any particular harm but it is quite confusing. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Bug-Debian: https://bugs.debian.org/961673 | 
| pc verifiers module.patch | (download) | 
              grub-core/Makefile.am |
                    2 	2 +	0 -	0 ! | i386-pc: build verifiers api as module Given no core functions on i386-pc would require verifiers to work and the only consumer of the verifier API is the pgp module, it looks good to me that we can move the verifiers out of the kernel image and let moddep.lst to auto-load it when pgp is loaded on i386-pc platform. This helps to reduce the size of core image and thus can relax the tension of exploding on some i386-pc system with very short MBR gap size. See also a very comprehensive summary from Colin [1] about the details. [1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00240.html V2: Drop COND_NOT_i386_pc and use !COND_i386_pc. Add comment in kern/verifiers.c to help understanding what's going on without digging into the commit history. Reported-by: Colin Watson <cjwatson@debian.org> | 
| debug_verifiers.patch | (download) | 
              grub-core/kern/verifiers.c |
                    2 	2 +	0 -	0 ! | add debug to display what's going on with verifiers Patch-Name: debug_verifiers.patch | 
| mkimage fix section sizes.patch | (download) | 
              util/mkimage.c |
                   21 	12 +	9 -	0 ! | util/mkimage: some fixes to pe binaries section size calculation Commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper) added a helper function to setup PE sections, but it caused regressions in some arches where the natural alignment lead to wrong section sizes. This patch fixes a few things that were caused the section sizes to be calculated wrongly. These fixes are: * Only align the virtual memory addresses but not the raw data offsets. * Use aligned sizes for virtual memory sizes but not for raw data sizes. * Always align the sizes to set the virtual memory sizes. These seems to not cause problems for x64 and aa64 EFI platforms but was a problem for ia64. Because the size of the ".data" and "mods" sections were wrong and didn't have the correct content. Which lead to GRUB not being able to load any built-in module. Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Bug-Debian: https://bugs.debian.org/987103 Patch-Name: mkimage-fix-section-sizes.patch | 
| Only show os prober disable warning if installed.patch | (download) | 
              util/grub.d/30_os-prober.in |
                    8 	4 +	4 -	0 ! | only show os-prober disable warning if installed It isn't very useful to see this message when os-prober is not even available. | 
| secure boot/disable efi fallback to legacy.patch | (download) | 
              grub-core/loader/efi/linux.c |
                   16 	0 +	16 -	0 ! | disable fallback to legacy mode if shim is loaded on x86 archs | 
| secure boot/efi peimage.patch | (download) | 
              grub-core/Makefile.core.def |
                   13 	13 +	0 -	0 ! | efi/peimage: provide an implementation of load_image, start_image, unload_image The code consumes a PE-COFF image loaded into memory. The functions * check validity of header * copy the sections * relocate the code * set memory attributes * invalidate the instruction cache * execute the image * return to caller Caveats: - We do not always check for over and underflows, but at the point we reach this loader, the file has been verified by shim already, so this is not much of a concern. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> Signed-off-by: Mate Kukri <mate.kukri@canonical.com> | 
| zstd require 8 byte buffer.patch | (download) | 
              grub-core/lib/zstd/entropy_common.c |
                    6 	3 +	3 -	0 ! |  zstd: require at least 8 byte buffer in entropy_common
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
This fixes the build on s390x which was rightfully complaining that
iend - 7 = buffer + 4 - 7 = buffer -3 is outside the array bounds.
../../grub-core/lib/zstd/entropy_common.c: In function FSE_readNCount:
../../grub-core/lib/zstd/entropy_common.c:121:28: error: array subscript -3 is outside array bounds of char[4] [-Werror=array-bounds]
  121 |             if ((ip <= iend-7) || (ip + (bitCount>>3) <= iend-4)) {
      |                        ~~~~^~
../../grub-core/lib/zstd/entropy_common.c:77:14: note: while referencing buffer
   77 |         char buffer[4];
      |              ^~~~~~
../../grub-core/lib/zstd/entropy_common.c:105:30: error: array subscript -1 is outside array bounds of char[4] [-Werror=array-bounds]
  105 |                 if (ip < iend-5) {
      |                          ~~~~^~
../../grub-core/lib/zstd/entropy_common.c:77:14: note: while referencing buffer
   77 |         char buffer[4];
      |              ^~~~~~
../../grub-core/lib/zstd/entropy_common.c:150:28: error: array subscript -3 is outside array bounds of char[4] [-Werror=array-bounds]
  150 |             if ((ip <= iend-7) || (ip + (bitCount>>3) <= iend-4)) {
      |                        ~~~~^~
../../grub-core/lib/zstd/entropy_common.c:77:14: note: while referencing buffer
   77 |         char buffer[4];
      |              ^~~~~~
This is fixed in more recent zstd versions in basically the same way,
but the new versions needs more work to import.
Patch-Name: zstd-require-8-byte-buffer.patch
 | 
| recovery dis_ucode_ldr.patch | (download) | 
              util/grub.d/10_linux.in |
                    4 	4 +	0 -	0 ! | pass dis_ucode_ldr to kernel for recovery mode In case of a botched microcode update, this allows people to easily roll back. It will of course break in the more unlikely event that you are missing a microcode update in your firmware that is needed to boot the system, but editing the entry to remove an option is easier than having to figure out the option and add it. LP: #1831789 | 
| hwmatch only on grub pc platform.patch | (download) | 
              util/grub.d/10_linux.in |
                    4 	3 +	1 -	0 ! |  call hwmatch only on the grub-pc platform
Call hwmatch only on i386/pc as it is only available there.
This avoids "error: can't find command `hwmatch'." on e.g., x86_64/efi.
The equivalent behavior is linux_gfx_mode=keep because grub is special:
the `if hwmatch` clause is true on that error and `$match = 0` is true
too, as it is undefined (confirmed in grub shell.) A quick fix for now.
Before and After:
    grub> hwmatch
    error: can't find command `hwmatch'.
    grub> echo $grub_platform
    efi
    grub> echo $linux_gfx_mode
    keep
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1840560
Bug-Debian: https://bugs.debian.org/990836
 | 
| fat fix listing the root directory.patch | (download) | 
              grub-core/fs/fat.c |
                   12 	12 +	0 -	0 ! | fat: fix listing the root directory ls / for a FAT partition leads to error: invalid modification timestamp for /. Not all entries of the directory are displayed. Linux never updates the modification timestamp of the /. directory entry. The FAT specification allows the access and creation date fields to be zero. We should follow Linux and render initial FAT timestamps as start of the epoch. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> | 
| efivar check that efivarfs is writeable.patch | (download) | 
              grub-core/osdep/unix/efivar.c |
                   34 	34 +	0 -	0 ! | efivar: check that efivarfs is writeable Some UEFI implementations (notably U-Boot) don't implement the SetVariable() runtime service. On these systems the GRUB installation must be completed manually. Write a warning in this case but avoid throwing an error. (LP: #1965288) Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> | 
| fdt add debug output to devicetree command.patch | (download) | 
              grub-core/loader/efi/fdt.c |
                    2 	2 +	0 -	0 ! | fdt: add debug output to devicetree command For debugging we need feedback that the devicetree command has be executed. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> | 
| fdt device tree fixup protocol.patch | (download) | 
              grub-core/loader/efi/fdt.c |
                   37 	37 +	0 -	0 ! | efi: efi device tree fixup protocol Device-trees are used to convey information about hardware to the operating system. Some of the properties are only known at boot time. (One example of such a property is the number of the boot hart on RISC-V systems.) Therefore the firmware applies fix-ups to the original device-tree. Some nodes and properties are added or altered. When using GRUB's device-tree command the same fix-ups have to be applied. The EFI Device Tree Fixup Protocol allows to pass the loaded device tree to the firmware for this purpose. The protocol can * add nodes and update properties * reserve memory according to the /reserved-memory node and the memory reservation block * install the device-tree as configuration table With the patch GRUB checks if the protocol is installed and invokes it if available. (LP: #1965796) Link: https://lists.gnu.org/archive/html/grub-devel/2021-02/msg00013.html Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> | 
| upstream/fs xfs Propagate incorrect inode error from grub_xfs_read.patch | (download) | 
              grub-core/fs/xfs.c |
                   14 	12 +	2 -	0 ! | fs/xfs: propagate incorrect inode error from grub_xfs_read_inode The incorrect inode error from grub_xfs_read_inode did not propagate because grub_print_error() resetted grub_errno, and grub_xfs_iterate_dir() did not handle it at all. Signed-off-by: Egor Ignatov <egori@altlinux.org> | 
