Your message dated Tue, 24 Oct 2006 15:29:09 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#390473: grub2: menuentry stanza doesn't accept $ { } in
variable substitutions
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: grub2
Version: 1.94+20060926-1
Severity: critical
Hello,
with the previous grub1 I had a Debian GNU/Hurd entry in my menu.lst:
=====
title Debian GNU/Hurd
root (hd0,9)
kernel /boot/gnumach.gz root=device:hd0s10
module /hurd/ext2fs.static \
--multiboot-command-line=${kernel-command-line} \
--host-priv-port=${host-port} \
--device-master-port=${device-port} \
--exec-server-task=${exec-task} \
-T typed ${root} $(task-create) $(task-resume)
module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
boot
=====
The first time I installed grub2 I "converted" that entry into the
grub2 config menu:
=====
menuentry "Debian GNU/Hurd" {
set root=(hd0,9)
multiboot /boot/gnumach.gz root=device:hd0s10
module /hurd/ext2fs.static \
--multiboot-command-line=${kernel-command-line} \
--host-priv-port=${host-port} \
--device-master-port=${device-port} \
--exec-server-task=${exec-task} \
-T typed ${root} $(task-create) $(task-resume)
module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
}
=====
After a `grub-install /dev/hda` and a reboot, grub2 entered in a panic
state at boot. Hopefully, the panic is reproducible, even on qemu:
create the following stanza (you can substitute $ with a second { ):
menuentry "test" { $ }
The panic is similar to the error generated with a $ at the beginning
of the grub.cfg file. While in the latter case grub2 can continue
booting, in n the former case the only way to solve it is to boot with
a rescue CD and remove the offending characters from grub2.cfg.
Trying to escape \$ \{ and \} doesn't solve the problem.
Thx, bye,
Gismo / Luca
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages grub2 depends on:
ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries
ii liblzo1 1.08-3 data compression library (old vers
ii libncurses5 5.5-4 Shared libraries for terminal hand
grub2 recommends no packages.
-- no debconf information
pgp9jCb4PNdnA.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
Closing due to lack of response.
On Sat, Oct 14, 2006 at 09:36:57PM +0200, Robert Millan wrote:
> On Fri, Oct 06, 2006 at 12:32:08PM +0200, Luca Capello wrote:
> > Hello!
> >
> > On Tue, 03 Oct 2006 12:46:14 +0200, Luca Capello wrote:
> > > I should note that thanks to the help of #hurd and #grub of Freenode
> > > (mostly marco_g ;-) ), the problem is solved escaping the "bad"
> > > characters within single quotes.
> >
> > As Javier-Elias Vasquez-Vivas noted on [EMAIL PROTECTED] [1] that the
> > solution provided here wasn't clear, I'm reporting the whole menuentry
> > stanza which works with grub2:
> > =====
> > menuentry "Debian GNU/Hurd" {
> > set root=(hd0,9)
> > multiboot /boot/gnumach.gz root=device:hd0s10
> > module /hurd/ext2fs.static \
> > --multiboot-command-line='${kernel-command-line}' \
> > --host-priv-port='${host-port}' \
> > --device-master-port='${device-port}' \
> > --exec-server-task='${exec-task}' \
> > -T typed '${root}' '$(task-create)' '$(task-resume)'
> > module /lib/ld.so.1 /hurd/exec '$(exec-task=task-create)'
> > }
> > =====
>
> According to upstream (IRC), this behaviour is consistent with GRUB2 having
> its
> own variable support (and namespace..). So you really need to use this new
> syntax (I'll take this into account for my work on update-grub2).
>
> Can we close this bug now?
>
> --
> Robert Millan
>
> My spam trap is [EMAIL PROTECTED] Note: this address is only intended for
> spam harvesters. Writing to it will get you added to my black list.
--
Robert Millan
My spam trap is [EMAIL PROTECTED] Note: this address is only intended for
spam harvesters. Writing to it will get you added to my black list.
--- End Message ---
