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>
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>
Patch-Name: bootp-process-dhcpack-http-boot.patch
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.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Ken Lin <ken.lin@hpe.com>
Patch-Name: efinet-uefi-ipv6-pxe-support.patch
Implement new net_bootp6 command for IPv6 network auto configuration via the
DHCPv6 protocol (RFC3315).
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Ken Lin <ken.lin@hpe.com>
Patch-Name: bootp-new-net_bootp6-command.patch
Allow specifying port numbers for http and tftp paths, and allow ipv6 addresses
to be recognized with brackets around them, which is required to specify a port
number
Patch-Name: net-read-bracketed-ipv6-addr.patch
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
Last-Update: 2016-11-01
Patch-Name: zpool-full-device-name.patch
Add fallback boot entries for alternative installed init systems. Based
on patches from Michael Biebl and Didier Roche.
Bug-Debian: https://bugs.debian.org/757298
Bug-Debian: https://bugs.debian.org/773173
Forwarded: no
Last-Update: 2017-06-23
Patch-Name: mkconfig-other-inits.patch
Add an extra option to grub-install "--force-extra-removable". On EFI
platforms, this will cause an extra copy of the grub-efi image to be
written to the appropriate removable media patch
/boot/efi/EFI/BOOT/BOOT$ARCH.EFI as well. This will help with broken
UEFI implementations where the firmware does not work when configured
with new boot paths.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Bug-Debian: https://bugs.debian.org/767037https://bugs.debian.org/773092
Forwarded: Not yet
Last-Update: 2014-12-20
Patch-Name: grub-install-extra-removable.patch
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
Forwarded: http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00091.html
Last-Update: 2014-11-30
Patch-Name: insmod-xzio-and-lzopio-on-xen.patch
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>
Origin: other, https://lists.gnu.org/archive/html/grub-devel/2014-09/msg00078.html
Last-Update: 2015-01-27
Patch-Name: ppc64el-disable-vsx.patch
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.)
Forwarded: no
Last-Update: 2014-10-15
Patch-Name: install-powerpc-machtypes.patch
This allows the controversial "recovery mode" text to be customised.
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1240360
Forwarded: no
Last-Update: 2013-12-25
Patch-Name: mkconfig-recovery-title.patch
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.
Author: Andy Whitcroft <apw@canonical.com>
Forwarded: not-needed
Last-Update: 2013-12-25
Patch-Name: vt-handoff.patch
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
Last-Update: 2019-06-24
Patch-Name: quick-boot-lvm.patch
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.
Author: Richard Laager <rlaager@wiktel.com>
Author: Robie Basak <robie.basak@ubuntu.com>
Forwarded: no
Last-Update: 2015-09-04
Patch-Name: quick-boot.patch
This is not a very good approach, and certainly not sanely upstreamable;
we probably need to split GRUB_DISTRIBUTOR into a couple of different
variables.
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1242417
Bug-Debian: https://bugs.debian.org/932966
Forwarded: not-needed
Last-Update: 2019-08-06
Patch-Name: install-efi-adjust-distributor.patch
Currently, gpt_offset is uninitialised when using a BIOS Boot Partition
but is used unconditionally inside save_blocklists. Instead, ensure it
is always initialised to 0 (note that there is already separate code to
do the equivalent adjustment after we call save_blocklists on this code
path).
This patch has been tested on a T5-2 LDOM.
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4e75b2ae313b13b5bfb54cc5e5c53368d6eb2a08
Bug-Debian: https://bugs.debian.org/931969
Last-Update: 2019-08-06
Patch-Name: sparc64-fix-bios-boot-partition-support.patch
Currently, gpt_offset is uninitialised when using a BIOS Boot Partition
but is used unconditionally inside save_blocklists. Instead, ensure it
is always initialised to 0 (note that there is already separate code to
do the equivalent adjustment after we call save_blocklists on this code
path).
This patch has been tested on a T5-2 LDOM.
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
---
util/setup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
MinGW for i386-pc without this option generates a .rdata$zzz symbol that is
page-aligned and hence lzma_decompress no longer fits in its allocated space.
Additionally, MinGW with -fno-ident also saves a bit of space in modules. In
case of other compilers we already strip the relevant sections, so, this
option has no effect.
More info can be found at https://github.com/msys2/MINGW-packages/issues/21
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The device tree may passed by the firmware as UEFI configuration
table. Let lsefisystab display a short text and not only the GUID
for the device tree.
Here is an example output:
grub> lsefisystab
Address: 0xbff694d8
Signature: 5453595320494249 revision: 00020046
Vendor: Das U-Boot, Version=20190700
2 tables:
0xbe741000 eb9d2d31-2d88-11d3-9a160090273fc14d SMBIOS
0x87f00000 b1b621d5-f19c-41a5-830bd9152c69aae0 DEVICE TREE
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following are two use cases from Rajat Jain <rajatjain@juniper.net>:
1) We have a board that boots Linux and this board itself can be plugged
into one of different chassis types. We need to pass different
parameters to the kernel based on the "CHASSIS_TYPE" information
that is passed by the bios in the DMI/SMBIOS tables.
2) We may have a USB stick that can go into multiple boards, and the
exact kernel to be loaded depends on the machine information
(PRODUCT_NAME etc) passed via the DMI.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This adds the GUID and includes it in lsefisystab output.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Blocklist fallout cleanup after commit 5c6f9bc15 (generic/blocklist: Fix
implicit declaration of function grub_file_filter_disable_compression()).
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The offset calculation was missing the relocation addend.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Tested-by: Chester Lin <clin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When building for arm, we already disable movw/movt relocations for clang,
since they are incompatible with PE.
When building with bare metal GCC toolchains (like the one used in the
travis ci scripts), we end up with these relocations again. So add an
additional test for the '-mword-relocations' flag used by GCC.
Reported-by: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Linux supports root=PARTUUID=<partuuid> boot argument, so add
support for probing it. Compared to the fs UUID, the partition
UUID does not change when reformatting a partition.
For now, only disks using a GPT partition table are supported.
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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: 2019-06-14
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
