Add support for multiple, shared, early initrd images. These early
images will be loaded in the order declared, and all will be loaded
before the initrd image.
While many classes of data can be provided by early images, the
immediate use case would be for distributions to provide CPU
microcode to mitigate the Meltdown and Spectre vulnerabilities.
There are two environment variables provided for declaring the early
images.
* GRUB_EARLY_INITRD_LINUX_STOCK is for the distribution declare
images that are provided by the distribution or installed packages.
If undeclared, this will default to a set of common microcode image
names.
* GRUB_EARLY_INITRD_LINUX_CUSTOM is for user created images. User
images will be loaded after the stock images.
These separate configurations allow the distribution and user to
declare different image sets without clobbering each other.
This also makes a minor update to ensure that UUID partition labels
stay disabled when no initrd image is found, even if early images are
present.
This is a continuation of a previous patch published by Christian
Hesse in 2016:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00025.html
Down stream Gentoo bug:
https://bugs.gentoo.org/645088
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Matthew S. Turnbull <sparky@bluefang-logic.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50
Author: Vladimir Serbinenko <phcoder@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The current documentation for the special environment variable
"default" is confusing and unclear. This patch attempts to clean it
up.
In particular, the current documentation refers to the "number or
title", but then in the example it gives, the menu entries and
submenus all have numbers *in* their title; furthermore, there is no
example given about how to choose the number, or any indication about
whether counting is zero-indexed or 1-indexed.
Having a cleaner example and presenting all variants (numeric, title,
and id) should make it clearer to the user.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Network boot autoconfiguration sets default server to next server IP
(siaddr) from BOOTP/DHCP reply, but manual configuration using net_bootp
exports only server name. Unfortunately semantic of server name is not
clearly defined. BOOTP RFC 951 defines it only for client request, and
DHCP RFC 1541 only mentions it, without any implied usage. It looks like
this field is mostly empty in server replies.
Export next server IP as net_<interface>_next_server variable. This allows
grub configuration script to set $root/$prefix based on information obtained
by net_bootp.
Reported and tested by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Cc: nikunj@linux.vnet.ibm.com
v2: change variable name to net_<interface>_next_server as discussed on the list
superusers controls both CLI and editing. Also explicitly mention that
empty superusers disables them.
"Access to menuentry" is a bit vague - change to "execute menuentry"
to make it obvious, what access is granted.
From RFC1542:
The 'giaddr' field is rather poorly named. It exists to facilitate
the transfer of BOOTREQUEST messages from a client, through BOOTP
relay agents, to servers on different networks than the client.
Similarly, it facilitates the delivery of BOOTREPLY messages from the
servers, through BOOTP relay agents, back to the client. In no case
does it represent a general IP router to be used by the client. A
BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all
BOOTREQUEST messages it generates.
A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY
message to be the IP address of an IP router. A BOOTP client SHOULD
completely ignore the contents of the 'giaddr' field in BOOTREPLY
messages.
Leave code ifdef'd out for the time being in case we see regression.
Suggested by: Rink Springer <rink@rink.nu>
Closes: 43396
* docs/grub-dev.texi (Font Metrics): Exclude @image command from DVI
builds, since we don't have an EPS version of font_char_metrics.png.
Add leading dot to image extension per the Texinfo documentation.
Add a new timeout_style environment variable and a corresponding
GRUB_TIMEOUT_STYLE configuration key for grub-mkconfig. This
controls hidden-timeout handling more simply than the previous
arrangements, and pressing any hotkeys associated with menu entries
during the hidden timeout will now boot the corresponding menu entry
immediately.
GRUB_HIDDEN_TIMEOUT=<non-empty> + GRUB_TIMEOUT=<non-zero> now
generates a warning, and if it shows the menu it will do so as if
the second timeout were not present. Other combinations are
translated into reasonable equivalents.
Remove reference to grub-default from description of saved default entry.
Also mention that GRUB_DEFAULT=saved depends on availability of environment
block.
