From: Thomas Huth <1860914@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1860914] Re: QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification
Date: Thu, 17 Jun 2021 07:09:50 -0000 [thread overview]
Message-ID: <162391379022.10888.12425632028509120001.malone@soybean.canonical.com> (raw)
In-Reply-To: 158004768486.19485.8886711795112517187.malonedeb@gac.canonical.com
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/425
** Changed in: qemu
Status: Incomplete => Expired
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #425
https://gitlab.com/qemu-project/qemu/-/issues/425
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860914
Title:
QEMU prepends pathnames to command lines of Multiboot kernels and
modules, contrary to the specification
Status in QEMU:
Expired
Bug description:
When QEMU is launched with the -kernel option to boot a Multiboot
image, the command line passed in the -append option is additionally
prefixed the pathname of the kernel image and a space. Likewise,
module command lines passed in the -initrd option are passed with the
module pathname and a space prepended. At the very least the former is
contary to what is prescribed in the Multiboot specification, version
0.6.96[0], which says in §3.3:
> General-purpose boot loaders should allow user a complete control on
command line independently of other factors like image name.
With respect to module command lines, the spec is less clear, but GNU
GRUB2 (the de facto reference implementation) does not prepend
pathnames to command lines of either. I haven't tested GRUB legacy,
but I assume it exhibits the same behaviour. It would be strange if
passing pathnames was in fact intended; bootloader pathnames are
useless to the loaded kernel, which may potentially have a completely
different view of the file system from the bootloader.
Also, given that a kernel pathname may contain spaces, skipping it in
the command line cannot be done reliably, while loading a Multiboot
module from a pathname that contains spaces is outright impossible.
Found in 4.2.0, but latest git master apparently behaves the same.
[0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1860914/+subscriptions
prev parent reply other threads:[~2021-06-17 7:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 14:08 [Bug 1860914] [NEW] QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification felix
2020-06-14 7:01 ` [Bug 1860914] " felix
2021-05-11 5:20 ` Thomas Huth
2021-06-17 7:09 ` Thomas Huth [this message]
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=162391379022.10888.12425632028509120001.malone@soybean.canonical.com \
--to=1860914@bugs.launchpad.net \
--cc=qemu-devel@nongnu.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.