Extra arguments given to chainloader on EFI platforms will be sent to
the chainloaded application. Also, minor edit in the chainloading section
to note that chainloading can be a jump via the firmware and not
necessarily in real mode (which does not exist on some achitectures).
Signed-off-by: Glenn Washburn <developm...@efficientek.com>
---
docs/grub.texi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index e4c5517a6fc5..7ab1e0ab40ef 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -979,7 +979,7 @@ invoke shutdown machinery.
Operating systems that do not support Multiboot and do not have specific
support in GRUB (specific support is available for Linux, FreeBSD, NetBSD
and OpenBSD) must be chain-loaded, which involves loading another boot
-loader and jumping to it in real mode.
+loader and jumping to it in real mode or via the firmware.
The @command{chainloader} command (@pxref{chainloader}) is used to set this
up. It is normally also necessary to load some GRUB modules and set the
@@ -4031,10 +4031,13 @@ a list of commands that could use more documentation:
@node chainloader
@subsection chainloader
-@deffn Command chainloader [@option{--force}] file
+@deffn Command chainloader [@option{--force}] file [args...]
Load @var{file} as a chain-loader. Like any other file loaded by the
filesystem code, it can use the blocklist notation (@pxref{Block list
syntax}) to grab the first sector of the current partition with @samp{+1}.
+On EFI platforms, any arguments after @var{file} will be sent to the loaded
+image.
+
If you specify the option @option{--force}, then load @var{file} forcibly,
whether it has a correct signature or not. This is required when you want to
load a defective boot loader, such as SCO UnixWare 7.1.
--
2.34.1
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
