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.
