I know know why you call this a handler; it seems to me that it is
just a semi-generic list package. Am I missing something?
You can find a slighly more flexible and generic implementation here:
http://cvs.savannah.gnu.org/viewvc/hurd-l4/viengoos/list.h?root=hurd&view=markup
I've been using
At Fri, 29 Aug 2008 16:46:32 +0200,
Marco Gerards wrote:
> "Neal H. Walfield" <[EMAIL PROTECTED]> writes:
>
> > I know know why you call this a handler; it seems to me that it is
> > just a semi-generic list package. Am I missing something?
>
> Perhap
re general solution to the customization problem would be to load
a config file at image compilation time. This could be used to solve
my problem. However, as it is an additional level of indirection,
perhaps both options would be useful.
Thoughts?
Thanks,
Neal
2009-01-17 Neal H. Walfield
*
At Fri, 27 Feb 2009 22:41:47 +0100,
Robert Millan wrote:
> I will try. Does someone have a known-working Multiboot / ELF64 image I can
> test with?
You can try Viengoos:
http://plato.walfield.org/viengoos
Here is a grub.cfg menu entry:
menuentry "Viengoos" {
multiboot /viengoos -D 3
At Sat, 28 Feb 2009 00:06:29 +0100,
Robert Millan wrote:
> Thanks. I just fixed it.
I've tested it and it seems to work.
Thanks,
Neal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Taking a look at grub-mkrescue, it seems that it creates a
boot/grub/grub.cfg that executes an insmod for each specified module.
It then copies the overlay files overwriting the just-created
grub.cfg.
The user's grub.cfg should either be appended to the one created by
grub-mkrescue or there should
At Wed, 2 Sep 2009 02:49:39 +0100,
Colin Watson wrote:
> +#ifndef HAVE_VASPRINTF
> +
> +int
> +vasprintf (char **buf, const char *fmt, va_list ap)
> +{
> + /* Should be large enough. */
> + *buf = xmalloc (512);
> +
> + return vsprintf (*buf, fmt, ap);
> +}
> +
> +#endif
Perhaps check that the
