As used in Ubuntu and possibly other downstreams (maybe Debian one day),
as that breaks the build.

Closes: #1007706

Thanks, John Paul Adrian Glaubitz.

Closes: #952815

Changes-By: lintian-brush
Fixes: lintian: upstream-metadata-file-is-missing
See-also: https://lintian.debian.org/tags/upstream-metadata-file-is-missing.html
Fixes: lintian: upstream-metadata-missing-repository
See-also: https://lintian.debian.org/tags/upstream-metadata-missing-repository.html

Changes-By: lintian-brush
Fixes: lintian: package-uses-old-debhelper-compat-version
See-also: https://lintian.debian.org/tags/package-uses-old-debhelper-compat-version.html

Add missing ${misc:Depends} to Depends for grub-efi-ia32-signed-template, grub-efi-amd64-signed-template, grub-efi-arm64-signed-template.

Changes-By: lintian-brush
Fixes: lintian: debhelper-but-no-misc-depends
See-also: https://lintian.debian.org/tags/debhelper-but-no-misc-depends.html

Changes-By: lintian-brush
Fixes: lintian: tab-in-license-text
See-also: https://lintian.debian.org/tags/tab-in-license-text.html

Changes-By: lintian-brush
Fixes: lintian: trailing-whitespace
See-also: https://lintian.debian.org/tags/trailing-whitespace.html

Replace 'UNRELEASED' with 'unstable' in debian/NEWS

See merge request grub-team/grub!30

Version 2.06-1 has been uploaded to unstable.

This fixes build failures on armel, mips64el, mipsel, and ppc64el.

minilzo fails to build on a number of Debian release architectures
(armel, mips64el, mipsel, ppc64el) with errors such as:

  ../../grub-core/lib/minilzo/minilzo.c: In function 'lzo_memops_get_le16':
  ../../grub-core/lib/minilzo/minilzo.c:3479:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
   3479 |         * (lzo_memops_TU2p) (lzo_memops_TU0p) (dd) = * (const lzo_memops_TU2p) (const lzo_memops_TU0p) (ss); \
        |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ../../grub-core/lib/minilzo/minilzo.c:3530:5: note: in expansion of macro 'LZO_MEMOPS_COPY2'
   3530 |     LZO_MEMOPS_COPY2(&v, ss);
        |     ^~~~~~~~~~~~~~~~

The latest upstream version is 2.10, so updating to it seems like a good
idea on general principles, and it fixes builds on all the above
architectures.

The update procedure documented in the GRUB Developers Manual worked; I
just updated the version numbers to make it clear that it's been
executed recently.

Signed-off-by: Colin Watson <cjwatson@debian.org>

Forwarded: https://lists.gnu.org/archive/html/grub-devel/2021-11/msg00095.html
Last-Update: 2021-11-29

Patch-Name: minilzo-2.10.patch

Closes: #997100

This was only needed for upgrades from before jessie.

We need to clear `grub_errno` after handling a memory allocation
failure, otherwise we mistakenly report "out of memory" shortly
afterwards.

The "ide-drive" device was removed in QEMU 6.0. The "ide-hd" has been
available for more than 10 years now in QEMU. Thus there shouldn't be
any need for backwards compatible names.

Signed-off-by: Marius Bakke <marius@gnu.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=aaea244a6ddd1e35aed60a5c7a08ddc41f51805b
Last-Update: 2021-09-24

Patch-Name: tests-ahci-update-qemu-device-name.patch

The commit 8b1e5d19 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes.
This change extended grub_xfs_inode struct by 76 bytes but also changed
the computation of XFS_V2_INODE_SIZE and XFS_V3_INODE_SIZE. Prior this
commit, XFS_V2_INODE_SIZE was 100 bytes. After the commit it's 84 bytes
XFS_V2_INODE_SIZE becomes 16 bytes too small.

As a result, the data structures aren't properly aligned and the GRUB
generates "attempt to read or write outside of partition" errors when
trying to read the XFS filesystem:

                             GNU GRUB  version 2.11
	....
	grub> set debug=efi,gpt,xfs
	grub> insmod part_gpt
	grub> ls (hd0,gpt1)/
	partmap/gpt.c:93: Read a valid GPT header
	partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125
	fs/xfs.c:931: Reading sb
	fs/xfs.c:270: Validating superblock
	fs/xfs.c:295: XFS v4 superblock detected
	fs/xfs.c:962: Reading root ino 128
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (739521961424144223) - 344365866970255880, 3840
	error: attempt to read or write outside of partition.

This commit change the XFS_V2_INODE_SIZE computation by subtracting 76
bytes instead of 92 bytes from the actual size of grub_xfs_inode struct.
This 76 bytes value comes from added members:
	20 grub_uint8_t   unused5
	 1 grub_uint64_t  flags2
        48 grub_uint8_t   unused6

This patch explicitly splits the v2 and v3 parts of the structure.
The unused4 is still ending of the v2 structures and the v3 starts
at unused5. Thanks to this we will avoid future corruptions of v2
or v3 inodes.

The XFS_V2_INODE_SIZE is returning to its expected size and the
filesystem is back to a readable state:

                      GNU GRUB  version 2.11
	....
	grub> set debug=efi,gpt,xfs
	grub> insmod part_gpt
	grub> ls (hd0,gpt1)/
	partmap/gpt.c:93: Read a valid GPT header
	partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125
	fs/xfs.c:931: Reading sb
	fs/xfs.c:270: Validating superblock
	fs/xfs.c:295: XFS v4 superblock detected
	fs/xfs.c:962: Reading root ino 128
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:931: Reading sb
	fs/xfs.c:270: Validating superblock
	fs/xfs.c:295: XFS v4 superblock detected
	fs/xfs.c:962: Reading root ino 128
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (131) - 64, 768
	efi/ fs/xfs.c:515: Reading inode (3145856) - 1464904, 0
	grub2/ fs/xfs.c:515: Reading inode (132) - 64, 1024
	grub/ fs/xfs.c:515: Reading inode (139) - 64, 2816
	grub>

Fixes: 8b1e5d19 (fs/xfs: Add bigtime incompat feature support)

Signed-off-by: Erwan Velu <e.velu@criteo.com>
Tested-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a4b495520e4dc41a896a8b916a64eda9970c50ea
Last-Update: 2021-09-24

Patch-Name: xfs-fix-v4-superblock.patch

Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>

Bug-Debian: https://bugs.debian.org/940911
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1848892
Last-Update: 2021-09-24

Patch-Name: tpm-unknown-error-non-fatal.patch

Commit f60ba9e5 (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

Patch-Name: debug_verifiers.patch

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>
Reviewed-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Michael Chang <mchang@suse.com>

Origin: other, https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00251.html
Bug-Debian: https://bugs.debian.org/984488
Bug-Debian: https://bugs.debian.org/985374
Last-Update: 2021-09-24

Patch-Name: pc-verifiers-module.patch

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
Last-Update: 2020-05-29

Patch-Name: xen-no-xsm-policy-in-non-xsm-options.patch

Patch-Name: dejavu-font-path.patch

In this case, we need both the signed shim as /EFI/BOOT/BOOTXXX.EFI
and signed Grub as /EFI/BOOT/grubXXX.efi.

Also install the BOOTXXX.CSV into /EFI/debian, and FBXXX.EFI into
/EFI/BOOT/ so that it can work when needed (*iff* we're updating the
NVRAM).

[cjwatson: Refactored also_install_removable somewhat for brevity and so
that we're using consistent case-insensitive logic.]

Bug-Debian: https://bugs.debian.org/930531
Last-Update: 2021-09-24

Patch-Name: grub-install-removable-shim.patch

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
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00119.html
Last-Update: 2019-03-23

Patch-Name: efi-variable-storage-minimise-writes.patch

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
Last-Update: 2019-02-10

Patch-Name: uefi-secure-boot-cryptomount.patch

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
Last-Update: 2019-02-09

Patch-Name: at_keyboard-module-init.patch

These don't work with and aren't needed by dynamically-loaded
completions.

Bug-Debian: https://bugs.debian.org/912852
Forwarded: no
Last-Update: 2018-11-16

Patch-Name: bash-completion-drop-have-checks.patch

Bug-Debian: https://bugs.debian.org/906470
Last-Update: 2018-10-28

Patch-Name: skip-grub_cmd_set_date.patch

grub currently copies the entire boot_params, which includes setting
sentinel byte to 0xff, which triggers sanitize_boot_params in the kernel
which in turn clears various boot_params variables, including the
indication that the bootloader chain is verified and thus the kernel
disables lockdown mode.  According to the information on the Fedora bug
tracker, only the information from byte 0x1f1 is necessary, so start
copying from there instead.

Author: Luca Boccassi <bluca@debian.org>
Bug-Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1418360
Forwarded: no

Patch-Name: fix-lockdown.patch

In the URI device path node, any name rahter 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 the 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>

Last-Update: 2021-09-24

Patch-Name: efinet-set-dns-from-uefi-proto.patch

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 of Uniform Resource Identifiers (URI) Device Path

grub-core/net/drivers/efi/efinet.c:
Check if PXE Base Code is available, if not it will 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 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>

Patch-Name: efinet-set-network-from-uefi-devpath.patch

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 obseleted because the HTTP
URL already contains the server address for the boot file. For DHCP6 config,
there's no difference definition in existing config as dhcp6.bootfile-url can
be used to specify URL for both HTTP and PXE boot file.

This patch adds processing for "HTTPClient" vendor class identifier in DHCPACK
packet by treating it as HTTP format, not as the PXE format.

Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Ken Lin <ken.lin@hpe.com>

Last-Update: 2021-09-24

Patch-Name: bootp-process-dhcpack-http-boot.patch