From: Robert Millan <rmh@aybabtu.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [multiboot] command-line format
Date: Wed, 20 Jan 2010 00:47:29 +0100 [thread overview]
Message-ID: <20100119234729.GQ8599@thorin> (raw)
In-Reply-To: <2e59e6971001171139t6e160e62racf34f08c3a38449@mail.gmail.com>
On Sun, Jan 17, 2010 at 01:39:48PM -0600, richardvoigt@gmail.com wrote:
>
> I think a bootloader with "universal" in its name should be doing
> everything possible to avoid this. If I want to multiboot between
> Linux, NetBSD, OpenSolaris, and OpenBSD, do I load my MBR with the BSD
> fork of GRUB, the Linux fork of GRUB, or the Solaris fork of GRUB?
It doesn't matter, because whichever version of GRUB you use should
generate a grub.cfg that uses multiboot command with appropiate
parameters.
> I think that defaulting the first parameter to the value used by what,
> 90% of kernels, but providing a way to override it (I like the
> variable idea) will be the least surprising for users. The path is
> filesystem-relative anyway, so GRUB isn't required to know how the
> kernel names its devices, nor do changes to grub device addressing
> change the parameter passed.
Filesystem-relative paths still reflect GRUB's view and aren't really a good
solution for system tools (which deals with absolute paths and mount points
instead). And even then, there are details like weird characters, slashes,
case sensitivity, etc which might differ.
If you still want GRUB's point of view, you can simply replace:
GRUB_PATH=$(make_system_path_relative_to_its_root ${SYSTEM_PATH})
prepare_grub_to_access_device ${SYSTEM_PATH}
echo "multiboot ${GRUB_PATH}"
with:
GRUB_PATH=$(make_system_path_relative_to_its_root ${SYSTEM_PATH})
prepare_grub_to_access_device ${SYSTEM_PATH}
echo "multiboot ${GRUB_PATH} ${GRUB_PATH}"
in your mkconfig script. But it is much more straightforward to simply do:
GRUB_PATH=$(make_system_path_relative_to_its_root ${SYSTEM_PATH})
prepare_grub_to_access_device ${SYSTEM_PATH}
echo "multiboot ${GRUB_PATH} ${SYSTEM_PATH}"
Then your system tools obtain a path that makes sense to them.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
next prev parent reply other threads:[~2010-01-19 23:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 16:53 [multiboot] command-line format Grégoire Sutre
2010-01-14 19:07 ` Seth Goldberg
2010-01-14 23:24 ` Grégoire Sutre
2010-01-14 23:41 ` Seth Goldberg
2010-01-15 0:42 ` Grégoire Sutre
2010-01-15 16:15 ` Robert Millan
2010-01-17 18:02 ` Grégoire Sutre
2010-01-17 18:22 ` Robert Millan
2010-01-17 19:39 ` richardvoigt
2010-01-19 23:47 ` Robert Millan [this message]
2010-01-20 17:19 ` Grégoire Sutre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100119234729.GQ8599@thorin \
--to=rmh@aybabtu.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.