Re: grub2: menuentry stanza doesn't accept $ { } in variable substitutions

2006-10-03 Thread Luca Capello 
Hello all,

this is my first post on this list :-)

I'm resending my previous mail which was directly rejected: I was
aware of the fact that grub-devel is a subscribed-only list, but I
(erroneously) thought there was a sort of administrator.  Never
mind...

I'm posting here as suggested by Robert Millan, including the original
Debian bug report, available at:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390473

Thx, bye,
Gismo / Luca

On Tue, 03 Oct 2006 12:46:14 +0200, Luca Capello wrote:
> Hi Robert!
>
> To the grub-devel guys: attached the report of a grub2 bug I
> experienced on Debian (marco_g should already be aware of).  In case
> of replies, please cc: the Debian BTS and myself (I set R-T and M-F-T
> accordingly).
>
> On Mon, 02 Oct 2006 17:10:12 +0200, Robert Millan wrote:
>> Given that this is treated as a syntax error, I don't consider it to
>> be release critical (it is important, though, on the basis that a
>> non-release Debian platform depends on it).
>
> Well, given the definition of critical [1] and the fact that with the
> old menu.lst converted to grub.cfg my system broke, I chose critical.
> However, I agree that mine could be considered a not-so-common case,
> thus I'm fine with important :-)
>
>> I would like not to diverge from upstream, specialy since GNU/Hurd
>> is a platform we expect them to support.  Please, could you resend
>> your report to them ?  (grub-devel@gnu.org).
>
> Done (and marked the Debian bug as forwarded).
>
> 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.
>
> Anyway, I still consider it an important bug (at least because there's
> no documentation for it).  Waiting for an upstream solution, I'll put
> a note in the README.Debian (or better in the NEWS.Debian, which is
> showed during upgrades).
>
> Thx, bye,
> Gismo / Luca
>
> Footnotes: 
> [1] makes unrelated software on the system (or the whole system)
> break, or causes serious data loss, or introduces a security hole
> on systems where you install the package

--- 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  libc62.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


pgpNe7ugMiix3.pgp
Description: PGP signature
--- End Message ---


pgpt9eblKlTKT.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Grub for ia64 - function descriptors

2006-10-03 Thread Hollis Blanchard 
On Tue, 2006-10-03 at 06:04 +0200, [EMAIL PROTECTED] wrote:
> Selon Hollis Blanchard <[EMAIL PROTECTED]>:
> 
> >
> > On Mon, 02 Oct 2006 08:31:10 +0200, [EMAIL PROTECTED] said:
> > > Quoting Hollis Blanchard <[EMAIL PROTECTED]>:
> [...]
> > > > > >I assume IA64 is similar here, and given that, a
> > > > > > module_jump function implemented in assembly by each architecture
> > would
> > > > > > solve this problem.
> > > > > I'd prefer modules to export pointers. Seems to be easier to deal.
> > > >
> > > > I don't know what you mean; please elaborate (with pseudo-code if
> > > > possible).
> > >
> > > I'd propose modules export struct grub_dl.  This struct contains init and
> > > fini
> > > functions pointers.
> > > Getting the address of a data structure is much more portable.
> > > Dealing with function pointers would be a matter of the relocator.
> >
> > It looks like this is only done twice in the current code: mod->init and
> > mod->fini. Wouldn't it be easy to do this:
> > --- kern/dl.c   28 May 2006 23:01:43 -  1.12
> > +++ kern/dl.c   3 Oct 2006 02:15:51 -
> > @@ -380,9 +380,9 @@ grub_dl_resolve_symbols (grub_dl_t mod,
> >   return grub_errno;
> >
> >   if (grub_strcmp (name, "grub_mod_init") == 0)
> > -   mod->init = (void (*) (grub_dl_t)) sym->st_value;
> > +   mod->init = grub_dl_arch_func (sym->st_value);
> >   else if (grub_strcmp (name, "grub_mod_fini") == 0)
> > -   mod->fini = (void (*) (void)) sym->st_value;
> > +   mod->fini = grub_dl_arch_func (sym->st_value);
> >   break;
> >
> > case STT_SECTION:
> To create descriptor, grub_dl_arch_func have to grub_malloc memory.  How to 
> free
> it ?

What about this:
grub_dl_arch_func(&mod->init, sym->st_value);

> I always prefer to use static memory when I can do that: code is smaller and
> safer.  That's the reason why I'd prefer to have struct grub_dl declared 
> static.
> Of course this is just my opinion.

Sure, and I'm not really opposed to exporting a struct grub_dl from
modules; I'm just trying to make sure we don't overcomplicate what could
be a simple change. Do you have a patch illustrating your idea?

-Hollis



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel