Re: grub-pc: installation failure under linux + udev
On Thu, Jan 03, 2008 at 11:14:23PM +0100, Pascal A. Dupuis wrote: > Hello, > > this is a copy of debian bug 450709 > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450709) at > debian maintainer's (Robert Millan ) request: Thanks Pascal. > But ... util/biosdisk.c has another issue with detecting udev. The > routine has_devfs searchs for /dev/.devfsd, which cames from deprecated > devfs. Enclosed is a synthetic patch, I compiled and ran it fine on my > machine. Could you check ? The off-by-5 bug is already fixed in CVS. As for the devfs part, I think I figured out what you're doing. You setup udev to emulate devfs-style devices, right? I think the right fix for this is not to check for /dev/.udev, but rather just probe for devfs-style devices unconditionally. As it happens there are other ways in which one could have this layout, including other /dev implementations such as userdevfs. What does everyone else think? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using UTF-8 in grub2 env
On Thu, Jan 03, 2008 at 06:29:54PM -0500, Pavel Roskin wrote: > > On Fri, 2008-01-04 at 00:18 +0100, Robert Millan wrote: > > > I can't reproduce this. What's in your grub.cfg ? > > My bad. It has "terminal console" in it. It's just a standard grub.cfg > generated by update-grub. :-) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using UTF-8 in grub2 env
On Fri, 2008-01-04 at 00:18 +0100, Robert Millan wrote: > I can't reproduce this. What's in your grub.cfg ? My bad. It has "terminal console" in it. It's just a standard grub.cfg generated by update-grub. Now I'm getting the graphical menu! -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using UTF-8 in grub2 env
On Thu, Jan 03, 2008 at 03:35:57PM -0500, Pavel Roskin wrote: > > On Thu, 2008-01-03 at 21:22 +0100, Robert Millan wrote: > > On Thu, Jan 03, 2008 at 12:49:04PM -0500, Pavel Roskin wrote: > > > > > > The menu doesn't work in gfxterm yet. > > > > It works for me. What problem did you find? > > When in qemu, "configfile (ata2)/grub.cfg" switches to the text mode and > then shows the menu. Subsequent "c" shows the prompt in the text mode. I can't reproduce this. What's in your grub.cfg ? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using UTF-8 in grub2 env
On Thu, 2008-01-03 at 21:22 +0100, Robert Millan wrote: > On Thu, Jan 03, 2008 at 12:49:04PM -0500, Pavel Roskin wrote: > > > > The menu doesn't work in gfxterm yet. > > It works for me. What problem did you find? When in qemu, "configfile (ata2)/grub.cfg" switches to the text mode and then shows the menu. Subsequent "c" shows the prompt in the text mode. Just in case, I made the iso image with grub-mkrescue using all modules (even ata) and then appended unifont.pff and grub.cfg with growisofs -r -M grub2.iso unifont.pff grub.cfg -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using UTF-8 in grub2 env
On Thu, Jan 03, 2008 at 12:49:04PM -0500, Pavel Roskin wrote: > > The menu doesn't work in gfxterm yet. It works for me. What problem did you find? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using UTF-8 in grub2 env
On Thu, Jan 03, 2008 at 04:55:16PM +, Oleg Strikov wrote: > Good day! > Is there any way to grub_printf() UTF-8 string? > I wanna make some i18n output using cyrillic symbols (with L"strings"), but > i get only "?" :( Did you setup gfxterm as per instructions in http://grub.enbug.org/gfxterm ? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Conditional Statement in Grub 2
I think I found the archives in bug-grub. Sorry I didn't see it earlier. Antonio ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: git mirror available
On Mon, 2007-12-24 at 14:29 +0800, Bean wrote: > I guess we could put the mirror in a public hosting, such as: > > http://repo.or.cz/ > > so that it's more reliable. Thanks for the suggestion. I wasn't aware that it's so easy to resister a project on that site. I have created a mirror there: http://repo.or.cz/w/grub2.git (that's the project's web page, see it for download instructions) -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using UTF-8 in grub2 env
On Thu, 2008-01-03 at 16:55 +, Oleg Strikov wrote: > Good day! > Is there any way to grub_printf() UTF-8 string? > I wanna make some i18n output using cyrillic symbols (with > L"strings"), but i get only "?" :( > Thanks! You need to load a Unicode font and switch to the graphical mode with "terminal gfxterm" See http://grub.enbug.org/gfxterm The menu doesn't work in gfxterm yet. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Using UTF-8 in grub2 env
Good day! Is there any way to grub_printf() UTF-8 string? I wanna make some i18n output using cyrillic symbols (with L"strings"), but i get only "?" :( Thanks! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] allow user-configurable menucolor
On Thu, Jan 03, 2008 at 06:04:59PM +0200, Vesa Jääskeläinen wrote: > > About error handling: > > Why not call grub_error() with error message and just return from > callback, and let prompt handle error processing (grub_print_error()). > This would keep error reporting centralized. One thing I don't like about grub_error() is that I never know what value to pick for the first parameter. I find this confusing :-/ -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Conditional Statement in Grub 2
Thanks for the reply Gregg. I think 0.97 is the path I will explore further. One last question. Do you know where the legacy archives are. I couldn't find them. Regards, Antonio - Original Message - From: "Gregg Levine" <[EMAIL PROTECTED]> To: "The development of GRUB 2" Sent: Wednesday, January 02, 2008 7:00 PM Subject: Re: Conditional Statement in Grub 2 On Jan 2, 2008 8:11 PM, Antonio Dupont <[EMAIL PROTECTED]> wrote: Hello, I apologize if this is the wrong list, but this is the list I have found through my searches. Please tell me where to go if this is not the proper place. I would like to have grub do a conditional statement similar to this: if file_name on /dev/cdrom matches file_name on /dev/sda1 (USB device) then boot Linux else boot Windows I've search through the Grub site and see there is some support for scripting, but I don't know how developed it is and if it can do what I'm asking. At the boot loader stage can it even see the cdrom or USB? I also saw in the older Grub archives "For scripting support, there are a lot of uses. For example booting a specific OS depending on the time. Some people requested that. If you look in the pupa-devel archives, you can find the examples Okuji gave." But, I can't find the pupa-devel archives, they seem to be off-line. I'm using CentOS 5.0 and if I can do it with Grub 0.97 that comes with the distro that would be great. I can also upgrade if needed. Any comments or direction would be much appreciated. Thanks and regards, Antonio ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel Hello! This is for the GRUB2 development efforts. Ideally you'd want the one for Grub-Legacy. Oh and if your release of GRUB-0.97 was patched by the Centos builders in some way we'll be able to advise you of course, but your advised to bring the matter to them. -- Gregg C Levine [EMAIL PROTECTED] "This signature was once found posting rude messages in English in the Moscow subway." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Quoting Robert Millan <[EMAIL PROTECTED]>: On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote: Quoting Robert Millan <[EMAIL PROTECTED]>: >>The module base address is calculated separately in kernel.elf and in >>grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage >>looks for the ELF segment with the highest end address. > >Ok, so you mean this setting: > > phdr->p_vaddr = grub_host_to_target32 (modbase); > phdr->p_paddr = grub_host_to_target32 (modbase); > >is not what it's used to calculate _end ? I can answer it now. No, it's not used to calculate _end, it needs to be incremented separately. OK, it turns out the values of _end actually match, so it's not a problem. It turns out there needs to be a gap between _end and the module base. 16k (0x4000) is not enough. 32k (0x8000) is enough. Why? Does the firmware impose this restriction, or is it GRUB itself that gets confused? I wish I knew it. 0x7000 is not OK, 0x8000 is OK. Less granularity makes no sense since the value is aligned at the 0x1000 boundary. This might differ from the init.c counterpart. There's an ALIGN_UP just a few lines above, if you set it to: modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN); both alignment and 0x8000 gap are still garanteed, without claiming more space than necessary. That is, if it really is a gap that you need :-) Thanks, that would be safer indeed, although it makes no difference for the values divisible by 0x1000. Can we make this work per inclusion rather than exclusion? The names of needed segments are well-known, right? Segments don't have names AFAIK. Sections have names. But anyway, it should be possible to recognize what we need. On the other hand, "work per inclusion" would make me nervous about breaking other architectures. We need to figure out why the extra gap is needed. Maybe something doesn't get counted. Yep. How did you find that an extra gap solves the problem? I started with the original boundary at 0x30, then I tried 0x3, then _end+0xb000 (_end is something like 0x2496c), then _end+0x1000 and so on, until I found that 0x7000 is not enough and 0x8000 is enough. It might be simpler than this. If you check what is the code flow between those two: disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `ide1/disk' failed. that'll give more details. There is a possibility that grub_errno remains set to some error. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] allow user-configurable menucolor
Robert Millan wrote: > On Thu, Jan 03, 2008 at 02:04:14AM +0100, Robert Millan wrote: >>> So, if you don't hesitate to create so many variables, you can simply >>> create "normal_color", "normal_background_color", "highlight_color" >>> and "highlight_background_color", although I don't know who would like it. >> Sounds like this could save us some code space. I'd go for _fg and _bg to >> preserve alignment in the names. > > Uhm actually, splitting those in _fg and _bg was a bit of a hassle, because > GRUB > internally thinks of colors as (bg << 4 | fg) like vga does, so obtaining them > from two separate variables didn't bring any real benefit. > > See attached new patch, using variable hooks. > > Note: if you're going to test this using "configfile" command, think that > this opens a new context and exposes the problem with hooks I just reported > in the other thread. About error handling: Why not call grub_error() with error message and just return from callback, and let prompt handle error processing (grub_print_error()). This would keep error reporting centralized. About new context: Shouldn't new context have clone of it's parent contexts settings? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <[EMAIL PROTECTED]>:
>
> >>The module base address is calculated separately in kernel.elf and in
> >>grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage
> >>looks for the ELF segment with the highest end address.
> >
> >Ok, so you mean this setting:
> >
> > phdr->p_vaddr = grub_host_to_target32 (modbase);
> > phdr->p_paddr = grub_host_to_target32 (modbase);
> >
> >is not what it's used to calculate _end ?
>
> OK, it turns out the values of _end actually match, so it's not a problem.
>
> It turns out there needs to be a gap between _end and the module base.
> 16k (0x4000) is not enough. 32k (0x8000) is enough.
Why? Does the firmware impose this restriction, or is it GRUB itself that
gets confused?
> This patch against the current CVS version fixes loading:
>
> diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c
> index 4727d7d..d2fa980 100644
> --- a/kern/powerpc/ieee1275/init.c
> +++ b/kern/powerpc/ieee1275/init.c
> @@ -231,5 +231,5 @@ grub_get_rtc (void)
> grub_addr_t
> grub_arch_modules_addr (void)
> {
> - return ALIGN_UP(_end, GRUB_MOD_ALIGN);
> + return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN);
> }
> diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c
> index 9e44af1..c39717a 100644
> --- a/util/elf/grub-mkimage.c
> +++ b/util/elf/grub-mkimage.c
> @@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char
> *mods[])
>phdr->p_offset = grub_host_to_target32 (ALIGN_UP
> (grub_util_get_fp_size (out),
> sizeof (long)));
>
> + modbase += 0x8000;
>load_modules (modbase, phdr, dir, mods, out);
> }
This might differ from the init.c counterpart. There's an ALIGN_UP just
a few lines above, if you set it to:
modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN);
both alignment and 0x8000 gap are still garanteed, without claiming more
space than necessary.
That is, if it really is a gap that you need :-)
> I haven't looked at binutils yet. Anyway, the problem doesn't exist
> with the current grub code because it suppressed build ID on
> kernel.elf. My workaround to get older grub compiled didn't actually
> strip build ID, it just fooled the objcopy test.
Ah, ok.
> But it would be great to detect and skip the segment corresponding to
> the build ID in grub-mkimage, just to make it more robust.
Can we make this work per inclusion rather than exclusion? The names
of needed segments are well-known, right?
> >>I actually doubt that it's the right behavior to go through segments.
> >
> >No idea about that I'm afraid :-(
>
> We need to figure out why the extra gap is needed. Maybe something
> doesn't get counted.
Yep. How did you find that an extra gap solves the problem?
> >>But maybe it's because in the normal mode with all modules loaded,
> >>unlike bare kernel.elf.
> >
> >But you don't need modules for ofdisk to work, it's built into the kernel.
>
> Just going to the rescue mode with the "rescue" command won't cause
> those hidden failures. It seems like they are caused by some missing
> module. I need to look into it.
It might be simpler than this. If you check what is the code flow between
those two:
disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `ide1/disk' failed.
that'll give more details.
--
Robert Millan
I know my rights; I want my phone call!
What use is a phone call, if you are unable to speak?
(as seen on /.)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Transparent decompression with file system filter
Bean wrote: > On Jan 3, 2008 7:19 AM, Yoshinori K. Okuji <[EMAIL PROTECTED]> wrote: >> Please wait a minute. Personally, I don't want grub_file_open to decompress a >> content automatically. The name should stand for what it does. That was why I >> named grub_file_open and grub_gzfile_open like this. This was really one of >> what I didn't like in GRUB Legacy. >> >> If you want to have a function to open any kind of compressed file, please >> add >> something else (e.g. grub_compressed_file_open). > > ok, i keep grub_file_open as it is, and add a new function > grub_zfile_open to handle compressed file. i also expand the list of > commands that use auto decompression: For me zfile doesn't say a thing. Where as name proposed by Okuji is clear to me instantly. Our current compilers can handle long symbol names fine, so why not use them if they make things clearer :) ? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] allow user-configurable menucolor
On Thu, Jan 03, 2008 at 02:04:14AM +0100, Robert Millan wrote: > > So, if you don't hesitate to create so many variables, you can simply > > create "normal_color", "normal_background_color", "highlight_color" > > and "highlight_background_color", although I don't know who would like it. > > Sounds like this could save us some code space. I'd go for _fg and _bg to > preserve alignment in the names. Uhm actually, splitting those in _fg and _bg was a bit of a hassle, because GRUB internally thinks of colors as (bg << 4 | fg) like vga does, so obtaining them from two separate variables didn't bring any real benefit. See attached new patch, using variable hooks. Note: if you're going to test this using "configfile" command, think that this opens a new context and exposes the problem with hooks I just reported in the other thread. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) * include/grub/normal.h (grub_env_write_color_normal): New prototype. (grub_env_write_color_highlight): Likewise. (grub_wait_after_message): Likewise. * normal/color.c: New file. * conf/i386-pc.rmk (grub_emu_SOURCES): Add `normal/color.c'. (normal_mod_DEPENDENCIES): Likewise. * normal/menu_entry.c (run): Rely on grub_wait_after_message() for waiting after a message is printed. * normal/main.c (read_config_file): Likewise. (grub_normal_init): Register grub_env_write_color_normal() and grub_env_write_color_highlight() hooks. Mark `color_normal' and `color_highlight' variables as global. * normal/menu.c (grub_wait_after_message): New function. (grub_color_menu_normal): New variable. Replaces ... (GRUB_COLOR_MENU_NORMAL): ... this macro. (grub_color_menu_highlight): New variable. Replaces ... (GRUB_COLOR_MENU_HIGHLIGHT): ... this macro. (draw_border): Set color state to `GRUB_TERM_COLOR_NORMAL' instead of `GRUB_TERM_COLOR_STANDARD'. (print_message): Use `grub_setcolorstate' to reload colors. Rename `normal_code' and `highlight_code' to `old_color_normal' and `old_color_highlight', respectively. (grub_menu_init_page): Update colors when drawing the menu, based on `menu_color_normal' and `menu_color_highlight' variables. (grub_menu_run): Rely on grub_wait_after_message() for waiting after a message is printed. diff -x '*~' -x '*.mk' -Nurp grub2/conf/i386-pc.rmk grub2.color/conf/i386-pc.rmk --- grub2/conf/i386-pc.rmk 2007-12-26 08:51:18.0 +0100 +++ grub2.color/conf/i386-pc.rmk 2008-01-03 15:01:09.0 +0100 @@ -111,7 +111,7 @@ grub_emu_SOURCES = commands/boot.c comma kern/loader.c kern/main.c kern/misc.c kern/parser.c \ grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c \ normal/arg.c normal/cmdline.c normal/command.c normal/function.c\ - normal/completion.c normal/main.c\ + normal/completion.c normal/main.c normal/color.c \ normal/menu.c normal/menu_entry.c normal/misc.c normal/script.c \ partmap/amiga.c partmap/apple.c partmap/pc.c partmap/sun.c \ partmap/acorn.c partmap/gpt.c \ @@ -168,6 +168,7 @@ normal_mod_DEPENDENCIES = grub_script.ta normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c \ normal/completion.c normal/execute.c \ normal/function.c normal/lexer.c normal/main.c normal/menu.c \ + normal/color.c \ normal/menu_entry.c normal/misc.c grub_script.tab.c \ normal/script.c normal/i386/setjmp.S normal_mod_CFLAGS = $(COMMON_CFLAGS) diff -x '*~' -x '*.mk' -Nurp grub2/include/grub/normal.h grub2.color/include/grub/normal.h --- grub2/include/grub/normal.h 2007-07-22 01:32:22.0 +0200 +++ grub2.color/include/grub/normal.h 2008-01-03 16:12:53.0 +0100 @@ -1,7 +1,7 @@ /* normal.h - prototypes for the normal mode */ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2002,2003,2005,2006,2007 Free Software Foundation, Inc. + * Copyright (C) 2002,2003,2005,2006,2007,2008 Free Software Foundation, Inc. * * GRUB is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -154,6 +154,9 @@ grub_err_t grub_normal_print_device_info grub_err_t grub_normal_menu_addentry (const char *title, struct grub_script *script, const char *sourcecode); +char *grub_env_write_color_normal (struct grub_env_var *var, const char *val); +char *grub_env_write_color_highlight (struct grub_env_var *var, const char *val); +void grub_wait_after_message (void); #ifdef GRUB_UTIL void grub_normal_init (void); diff -x '*~' -x '*.mk' -Nurp grub2/normal/color.c grub2.color/normal/color.c --- grub2/normal/color.c 1970-01-01 01:00:00.0 +0100 +++ grub2.color/normal/color.c 2008-01-03 15:44:48.0 +0100 @@ -0,0 +1,149 @@ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 1999,2000,2001,2002,2003,2004,2008 Free Software Foundation, Inc. + * + * GRUB is free software: you can redistribute it and/or modify + * it under the t
Re: variable hooks & global variables
I propose this patch to preserve hooks only when variables are already
marked as global.
Additionally, it exports "root" variable.
On Thu, Jan 03, 2008 at 04:05:58PM +0100, Robert Millan wrote:
> On Thu, Jan 03, 2008 at 04:03:11PM +0100, Robert Millan wrote:
> >
> > When you set a variable hook (grub_register_variable_hook), this hook isn't
> > preserved after someone (e.g. configfile command) opens a new context
> > (grub_env_context_open), unless the variable has been set as global
> > (grub_env_export).
> >
> > Is this what we want?
> >
> > The only current user of variable hooks is "root" variable, and that hook
> > contains a sanity check that seems to be more suitable for global scope.
> >
> > The color-related variables for which I wanted to add hooks would also
> > like to keep their hooks across contexts.
> >
> > One option is to export these variables, or to modify
> > grub_env_context_open()
> > to preserve hooks as well as exported variables. I'm more inclined for the
> > latter.
> >
> > Comments?
>
> Erm, ignore the part about global variables. Exporting them doesn't help:
>
> for (var = context->prev->vars[i]; var; var = var->next)
> {
> if (var->type == GRUB_ENV_VAR_GLOBAL)
> if (grub_env_set (var->name, var->value) != GRUB_ERR_NONE)
> {
> grub_env_context_close ();
> return grub_errno;
> }
> }
>
> So, we just preserve hooks ?
>
> --
> Robert Millan
>
> I know my rights; I want my phone call!
> What use is a phone call, if you are unable to speak?
> (as seen on /.)
--
Robert Millan
I know my rights; I want my phone call!
What use is a phone call, if you are unable to speak?
(as seen on /.)
* kern/env.c (grub_env_context_open): Propagate hooks for global
variables to new context.
* kern/main.c (grub_set_root_dev): Export `root' variable.
diff -x '*~' -x '*.mk' -Nurp grub2/kern/env.c grub2.color/kern/env.c
--- grub2/kern/env.c 2007-12-30 09:52:04.0 +0100
+++ grub2.color/kern/env.c 2008-01-03 16:13:20.0 +0100
@@ -1,7 +1,7 @@
/* env.c - Environment variables */
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2003,2005,2006,2007 Free Software Foundation, Inc.
+ * Copyright (C) 2003,2005,2006,2007,2008 Free Software Foundation, Inc.
*
* GRUB is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -96,11 +96,14 @@ grub_env_context_open (void)
for (var = context->prev->vars[i]; var; var = var->next)
{
if (var->type == GRUB_ENV_VAR_GLOBAL)
- if (grub_env_set (var->name, var->value) != GRUB_ERR_NONE)
- {
- grub_env_context_close ();
- return grub_errno;
- }
+ {
+ if (grub_env_set (var->name, var->value) != GRUB_ERR_NONE)
+ {
+ grub_env_context_close ();
+ return grub_errno;
+ }
+ grub_register_variable_hook (var->name, var->read_hook, var->write_hook);
+ }
}
}
diff -x '*~' -x '*.mk' -Nurp grub2/kern/main.c grub2.color/kern/main.c
--- grub2/kern/main.c 2007-07-22 01:32:26.0 +0200
+++ grub2.color/kern/main.c 2008-01-03 16:29:19.0 +0100
@@ -1,7 +1,7 @@
/* main.c - the kernel main routine */
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2002,2003,2005 Free Software Foundation, Inc.
+ * Copyright (C) 2002,2003,2005,2006,2008 Free Software Foundation, Inc.
*
* GRUB is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -78,6 +78,7 @@ grub_set_root_dev (void)
const char *prefix;
grub_register_variable_hook ("root", 0, grub_env_write_root);
+ grub_env_export ("root");
prefix = grub_env_get ("prefix");
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Quoting Robert Millan <[EMAIL PROTECTED]>:
The module base address is calculated separately in kernel.elf and in
grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage
looks for the ELF segment with the highest end address.
Ok, so you mean this setting:
phdr->p_vaddr = grub_host_to_target32 (modbase);
phdr->p_paddr = grub_host_to_target32 (modbase);
is not what it's used to calculate _end ?
OK, it turns out the values of _end actually match, so it's not a problem.
It turns out there needs to be a gap between _end and the module base.
16k (0x4000) is not enough. 32k (0x8000) is enough.
This patch against the current CVS version fixes loading:
diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c
index 4727d7d..d2fa980 100644
--- a/kern/powerpc/ieee1275/init.c
+++ b/kern/powerpc/ieee1275/init.c
@@ -231,5 +231,5 @@ grub_get_rtc (void)
grub_addr_t
grub_arch_modules_addr (void)
{
- return ALIGN_UP(_end, GRUB_MOD_ALIGN);
+ return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN);
}
diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c
index 9e44af1..c39717a 100644
--- a/util/elf/grub-mkimage.c
+++ b/util/elf/grub-mkimage.c
@@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char
*mods[])
phdr->p_offset = grub_host_to_target32 (ALIGN_UP
(grub_util_get_fp_size (out),
sizeof (long)));
+ modbase += 0x8000;
load_modules (modbase, phdr, dir, mods, out);
}
One problem in grub-mkimage is the infamous build ID, which is present
in kernel.elf. It is located in a loadable segment starting at
0x1d4 (i.e. just about 256M). That's what confuses objcopy, and
it must be confusing grub-mkimage as well.
Isn't build ID a recent change in binutils? We had this problem for a while.
I haven't looked at binutils yet. Anyway, the problem doesn't exist
with the current grub code because it suppressed build ID on
kernel.elf. My workaround to get older grub compiled didn't actually
strip build ID, it just fooled the objcopy test.
But it would be great to detect and skip the segment corresponding to
the build ID in grub-mkimage, just to make it more robust.
I actually doubt that it's the right behavior to go through segments.
No idea about that I'm afraid :-(
We need to figure out why the extra gap is needed. Maybe something
doesn't get counted.
Linux style description. The first line is the synopsis. If it
doesn't fit 72 characters, the patch is a candidate for splitting.
Then an empty line. Then a more detailed description of the patch,
including the motivation behind the changes. The list of the affected
files can be generated by the version control system.
Looks good. But I guess you'll have to convince Marco and Okuji
about this :-)
Sure, it's in my TODO list :)
But maybe it's because in the normal mode with all modules loaded,
unlike bare kernel.elf.
But you don't need modules for ofdisk to work, it's built into the kernel.
Just going to the rescue mode with the "rescue" command won't cause
those hidden failures. It seems like they are caused by some missing
module. I need to look into it.
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
multiboot.texi
I'd like to copy grub/docs/multiboot.texi into grub2 CVS, and start providing
it as part of the docs.
The copyright holders are:
Copyright @copyright{} 1995,96 Bryan Ford
Copyright @copyright{} 1995,96 Erich Stefan Boleyn
Copyright @copyright{} 1999,2000,2001,2002,2005,2006 Free Software
Foundation, Inc.
Is that fine?
After that, we might want to create multiboot2.texi as a draft based on this
one.
--
Robert Millan
I know my rights; I want my phone call!
What use is a phone call, if you are unable to speak?
(as seen on /.)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: variable hooks & global variables
On Thu, Jan 03, 2008 at 04:03:11PM +0100, Robert Millan wrote:
>
> When you set a variable hook (grub_register_variable_hook), this hook isn't
> preserved after someone (e.g. configfile command) opens a new context
> (grub_env_context_open), unless the variable has been set as global
> (grub_env_export).
>
> Is this what we want?
>
> The only current user of variable hooks is "root" variable, and that hook
> contains a sanity check that seems to be more suitable for global scope.
>
> The color-related variables for which I wanted to add hooks would also
> like to keep their hooks across contexts.
>
> One option is to export these variables, or to modify grub_env_context_open()
> to preserve hooks as well as exported variables. I'm more inclined for the
> latter.
>
> Comments?
Erm, ignore the part about global variables. Exporting them doesn't help:
for (var = context->prev->vars[i]; var; var = var->next)
{
if (var->type == GRUB_ENV_VAR_GLOBAL)
if (grub_env_set (var->name, var->value) != GRUB_ERR_NONE)
{
grub_env_context_close ();
return grub_errno;
}
}
So, we just preserve hooks ?
--
Robert Millan
I know my rights; I want my phone call!
What use is a phone call, if you are unable to speak?
(as seen on /.)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
variable hooks & global variables
When you set a variable hook (grub_register_variable_hook), this hook isn't preserved after someone (e.g. configfile command) opens a new context (grub_env_context_open), unless the variable has been set as global (grub_env_export). Is this what we want? The only current user of variable hooks is "root" variable, and that hook contains a sanity check that seems to be more suitable for global scope. The color-related variables for which I wanted to add hooks would also like to keep their hooks across contexts. One option is to export these variables, or to modify grub_env_context_open() to preserve hooks as well as exported variables. I'm more inclined for the latter. Comments? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Transparent decompression with file system filter
On Thu, Jan 03, 2008 at 08:53:19PM +0800, Bean wrote: > On Jan 3, 2008 7:35 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > > How does grub_zfile_open differ from grub_gzfile_open ? > > grub_gzfile_open only handle gzip file, while grub_zfile_open handle > compressed file in general. when module like gzio starts, it register > a structure that grub_zfile_open would use to call the decompression > routine. the binding is dynamic, the modules that use grub_zfile_open > doesn't depend on the specific decompression module. Ah, sounds nice. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Transparent decompression with file system filter
On Jan 3, 2008 7:35 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > How does grub_zfile_open differ from grub_gzfile_open ? grub_gzfile_open only handle gzip file, while grub_zfile_open handle compressed file in general. when module like gzio starts, it register a structure that grub_zfile_open would use to call the decompression routine. the binding is dynamic, the modules that use grub_zfile_open doesn't depend on the specific decompression module. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Thu, Jan 03, 2008 at 03:09:17AM -0500, Pavel Roskin wrote: > Quoting Robert Millan <[EMAIL PROTECTED]>: > > >just take the grub-mkimage.c part of it and try to revert it on CVS HEAD, > >that would confirm it's a grub-mkimage problem. Then apply the hunks > >selectively untill you find the exact change that broke it. And finally > >it's just a matter of "looking hard" at that hunk untill it's coerced to > >reveal the problem :-) > > OK, here's what I have so far. The patch tries to make the memory > layout more compact. Two changes are make to the layout. kernel.elf > is loaded at 64k instead of 2M and the modules are loaded at the > lowest 4k boundary after kernel.elf rather that at 3M. > > Moving the kernel.elf load address is fine. Moving the modules is not. > > The module base address is calculated separately in kernel.elf and in > grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage > looks for the ELF segment with the highest end address. Ok, so you mean this setting: phdr->p_vaddr = grub_host_to_target32 (modbase); phdr->p_paddr = grub_host_to_target32 (modbase); is not what it's used to calculate _end ? I thought _end was calculated by the ELF loader (our own ELF loader, multiboot.c seems to calculate _end and pass it to its payload). > One problem in grub-mkimage is the infamous build ID, which is present > in kernel.elf. It is located in a loadable segment starting at > 0x1d4 (i.e. just about 256M). That's what confuses objcopy, and > it must be confusing grub-mkimage as well. Isn't build ID a recent change in binutils? We had this problem for a while. > I actually doubt that it's the right behavior to go through segments. No idea about that I'm afraid :-( > Linux style description. The first line is the synopsis. If it > doesn't fit 72 characters, the patch is a candidate for splitting. > Then an empty line. Then a more detailed description of the patch, > including the motivation behind the changes. The list of the affected > files can be generated by the version control system. Looks good. But I guess you'll have to convince Marco and Okuji about this :-) > The linear ChangeLog with everybody changing it in the same place (in > the beginning) doesn't work well with parallel development. It's not that much of a problem, I just write them in the patch header and copy them at the last minute before commit. > >>disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'. > >>disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. > >>kern/disk.c:299: Opening `ide1/disk' failed. > >>kern/disk.c:312: Closing `ide1/disk'. > > > >This seems to be contradictory. If OF returned a handle, why does the > >open fail ? Looks like GRUB doesn't like something but isn't telling you > >what. I'd investigate that part; at the least it can mean our error > >handling isn't good enough. > > Actually, there are no "failures" with the version from 2007-02-20. Does a snapshot from 2007-02-21 also have this problem? > But maybe it's because in the normal mode with all modules loaded, > unlike bare kernel.elf. But you don't need modules for ofdisk to work, it's built into the kernel. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub-probe && FreeBSD
On Wed, Jan 02, 2008 at 08:59:04PM -0500, Francis Gendreau wrote: > > Also, if someone can email-me how to uses diff so I can create patch in > a single file, it would be greatly appreciated. :) diff -urp grub.old grub.new -r for recursive. -u is needed to prevent everyone's eyes from bleeding (for some odd reason, everyone prefers this but is still not the default). -p is often preferred in this list to track which functions you changed. Please resend your patch with the new params, it'll make it easier to review it. Also, remember to include a ChangeLog entry describing it. Thanks! -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Conditional Statement in Grub 2
On Thu, Jan 03, 2008 at 01:11:56AM -, Antonio Dupont wrote: > > > Hello, > > I apologize if this is the wrong list, but this is the list I have found > through my searches. Please tell me where to go if this is not the proper > place. > > I would like to have grub do a conditional statement similar to this: > > if file_name on /dev/cdrom matches file_name on /dev/sda1 (USB device) then > boot Linux else boot Windows You can do this with GRUB, the syntax I don't recall exactly but it is bash-like. > I'm using CentOS 5.0 and if I can do it with Grub 0.97 that comes with the > distro that would be great. I can also upgrade if needed. GRUB 2 only. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: spam in commit-grub
On Wed, Jan 02, 2008 at 11:19:20PM -0500, Gregg C Levine wrote: > Hello! > Who's the list-admin for commit-grub? I am thinking I can take that cover > for a few weeks and see what happens. And what about resetting the list so > that it requires a moderator to accept all posts, that way if something that > is really junk does materialize we can throw it out. I don't object to you doing that job, but I think it's unnecessary that: - Someone has to go through mails by hand. - We get each commit message with a delay. just to avoid having the list reject illegitimate posters, which can either be defined as: - Anyone except Savannah. - Anyone except Savannah and non-subscribers. commit-grub specificaly is not a list for public discussion. If we have this for grub-devel, I don't see why we can't have it for commit-grub as well. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Transparent decompression with file system filter
On Thu, Jan 03, 2008 at 04:49:24PM +0800, Bean wrote: > On Jan 3, 2008 7:19 AM, Yoshinori K. Okuji <[EMAIL PROTECTED]> wrote: > > > > On Monday 31 December 2007 17:59, Bean wrote: > > > Hi, > > > > > > Changes in this new patch: > > > > > > 1, change function name grub_file_open_raw to grub_file_ropen > > > 2, replace grub_file_open in command/blocklist.c and > > > util/i386/pc/grub-setup.c to grub_file_ropen. > > > > > > If nobody objects, i would like to commit this in a few days. > > > > Please wait a minute. Personally, I don't want grub_file_open to decompress > > a > > content automatically. The name should stand for what it does. That was why > > I > > named grub_file_open and grub_gzfile_open like this. This was really one of > > what I didn't like in GRUB Legacy. > > > > If you want to have a function to open any kind of compressed file, please > > add > > something else (e.g. grub_compressed_file_open). > > ok, i keep grub_file_open as it is, and add a new function > grub_zfile_open to handle compressed file. How does grub_zfile_open differ from grub_gzfile_open ? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Transparent decompression with file system filter
On Jan 3, 2008 7:19 AM, Yoshinori K. Okuji <[EMAIL PROTECTED]> wrote: > > On Monday 31 December 2007 17:59, Bean wrote: > > Hi, > > > > Changes in this new patch: > > > > 1, change function name grub_file_open_raw to grub_file_ropen > > 2, replace grub_file_open in command/blocklist.c and > > util/i386/pc/grub-setup.c to grub_file_ropen. > > > > If nobody objects, i would like to commit this in a few days. > > Please wait a minute. Personally, I don't want grub_file_open to decompress a > content automatically. The name should stand for what it does. That was why I > named grub_file_open and grub_gzfile_open like this. This was really one of > what I didn't like in GRUB Legacy. > > If you want to have a function to open any kind of compressed file, please add > something else (e.g. grub_compressed_file_open). ok, i keep grub_file_open as it is, and add a new function grub_zfile_open to handle compressed file. i also expand the list of commands that use auto decompression: ls to get the uncompressed file size in long list loopback to open compressed image file font to open compressed font file. -- Bean grub2-fshook4.diff Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Quoting Robert Millan <[EMAIL PROTECTED]>: just take the grub-mkimage.c part of it and try to revert it on CVS HEAD, that would confirm it's a grub-mkimage problem. Then apply the hunks selectively untill you find the exact change that broke it. And finally it's just a matter of "looking hard" at that hunk untill it's coerced to reveal the problem :-) OK, here's what I have so far. The patch tries to make the memory layout more compact. Two changes are make to the layout. kernel.elf is loaded at 64k instead of 2M and the modules are loaded at the lowest 4k boundary after kernel.elf rather that at 3M. Moving the kernel.elf load address is fine. Moving the modules is not. The module base address is calculated separately in kernel.elf and in grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage looks for the ELF segment with the highest end address. One problem in grub-mkimage is the infamous build ID, which is present in kernel.elf. It is located in a loadable segment starting at 0x1d4 (i.e. just about 256M). That's what confuses objcopy, and it must be confusing grub-mkimage as well. I actually doubt that it's the right behavior to go through segments. The "_end" marker should be located in a specific segment. And if the search through segments is correct, then maybe grub-mkimage should hardcore the module base into the output, rather than rely on kernel.elf doing the same calculation and getting the same result. All I need to to do fix the problem is to make kernel.elf and grub-mkimage come to the same value of the module base address. (Not to put any pressure of anyone, but GNU ChangeLog shows its age here - the detailed changes are described, but the motivation behind the whole patch is not, yet the details can be recovered with the version control, whereas the motivation has to be guessed) Full ack. But, you didn't mention any alternative. Linux style description. The first line is the synopsis. If it doesn't fit 72 characters, the patch is a candidate for splitting. Then an empty line. Then a more detailed description of the patch, including the motivation behind the changes. The list of the affected files can be generated by the version control system. The linear ChangeLog with everybody changing it in the same place (in the beginning) doesn't work well with parallel development. Both ide0/disk and cd refer to the CD-ROM. The messages are not shown if there is a CD in the drive. >What happens if you set debug=disk ? Typing from another monitor, sorry for possible typos. disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'. disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `ide1/disk' failed. kern/disk.c:312: Closing `ide1/disk'. This seems to be contradictory. If OF returned a handle, why does the open fail ? Looks like GRUB doesn't like something but isn't telling you what. I'd investigate that part; at the least it can mean our error handling isn't good enough. Actually, there are no "failures" with the version from 2007-02-20. But maybe it's because in the normal mode with all modules loaded, unlike bare kernel.elf. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
