Re: [joeyh@debian.org: Bug#243835: grub-install hangs with xfs root/boot]
On Thu, 2004-04-15 at 08:15, Yoshinori K. Okuji wrote: This sounds like a bug in XFS. Is it possible to get a stack trace from the grub shell by gdb to detect where it hangs up? There have been attempts to convince me to add calls to xfs_freeze around the use of grub. This then makes sure that the bits are written to the disk and that the kernel isn't moving things around. This still strikes me as a bit of a hack, though, so I've been a bit reluctant to actually go down this path. Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: automake mess
On Tue, 2003-09-09 at 13:58, Robert Millan wrote: I just found that GRUB is broken for automake 1.7: [snip] Anyone with a better clue on autotools than me could take it a look? The last time this came up, Okuji wanted to stay with 1.5. Your output almost looks like you're missing a perl module (perl-Data-Dumper). Once that's fixed, though, you also need the following patch (applies against 0.92 and 0.93, haven't tried against cvs recently) Jeremy diff -ur grub-0.92/configure.in grub/configure.in --- grub-0.92/configure.in Wed May 1 20:54:16 2002 +++ grub/configure.in Wed May 1 20:55:39 2002 @@ -55,8 +55,8 @@ _AM_DEPENDENCIES(CC) dnl Because recent automake complains about AS, set it here. -AS=$CC -AC_SUBST(AS) +CCAS=$CC +AC_SUBST(CCAS) AC_ARG_WITH(binutils, [ --with-binutils=DIR search the directory DIR to find binutils]) @@ -607,9 +607,9 @@ AC_SUBST(NET_EXTRAFLAGS) AC_SUBST(NETBOOT_DRIVERS) -dnl Because recent automake complains about ASFLAGS, set it here. -ASFLAGS='$(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)' -AC_SUBST(ASFLAGS) +dnl Because recent automake complains about CCASFLAGS, set it here. +CCASFLAGS='$(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)' +AC_SUBST(CCASFLAGS) AC_ARG_ENABLE(vga16, [ --disable-vga16disable VGA graphics interface]) diff -ur grub-0.92/stage1/Makefile.am grub/stage1/Makefile.am --- grub-0.92/stage1/Makefile.am Wed Jul 4 03:33:48 2001 +++ grub/stage1/Makefile.am Wed May 1 20:56:58 2002 @@ -4,7 +4,7 @@ CLEANFILES = $(nodist_pkgdata_DATA) # We can't use builtins or standard includes. -AM_ASFLAGS = $(STAGE1_CFLAGS) -fno-builtin -nostdinc +AM_CCASFLAGS = $(STAGE1_CFLAGS) -fno-builtin -nostdinc LDFLAGS = -nostdlib -Wl,-N,-Ttext,7C00 noinst_PROGRAMS = stage1.exec Only in grub/stage1: Makefile.am~ diff -ur grub-0.92/stage2/Makefile.am grub/stage2/Makefile.am --- grub-0.92/stage2/Makefile.am Sun Feb 3 23:55:48 2002 +++ grub/stage2/Makefile.am Wed May 1 20:57:51 2002 @@ -87,7 +87,7 @@ fsys_vstafs.c fsys_xfs.c hercules.c serial.c smp-imps.c \ stage2.c md5.c pre_stage2_exec_CFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) -pre_stage2_exec_ASFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) +pre_stage2_exec_CCASFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) pre_stage2_exec_LDFLAGS = $(PRE_STAGE2_LINK) if NETBOOT_SUPPORT @@ -108,7 +108,7 @@ echo #define STAGE2_SIZE $$6 stage2_size.h start_exec_SOURCES = start.S -start_exec_ASFLAGS = $(STAGE2_COMPILE) +start_exec_CCASFLAGS = $(STAGE2_COMPILE) start_exec_LDFLAGS = $(START_LINK) # XXX: automake doesn't provide a way to specify dependencies for object @@ -126,7 +126,7 @@ stage1_5.c fsys_ext2fs.c bios.c e2fs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ -DNO_BLOCK_FILES=1 -e2fs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ +e2fs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ -DNO_BLOCK_FILES=1 e2fs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -135,7 +135,7 @@ stage1_5.c fsys_fat.c bios.c fat_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FAT=1 \ -DNO_BLOCK_FILES=1 -fat_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FAT=1 \ +fat_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FAT=1 \ -DNO_BLOCK_FILES=1 fat_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -144,7 +144,7 @@ stage1_5.c fsys_ffs.c bios.c ffs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FFS=1 \ -DNO_BLOCK_FILES=1 -ffs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FFS=1 \ +ffs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FFS=1 \ -DNO_BLOCK_FILES=1 ffs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -153,7 +153,7 @@ stage1_5.c fsys_minix.c bios.c minix_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_MINIX=1 \ -DNO_BLOCK_FILES=1 -minix_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_MINIX=1 \ +minix_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_MINIX=1 \ -DNO_BLOCK_FILES=1 minix_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -162,7 +162,7 @@ disk_io.c stage1_5.c fsys_reiserfs.c bios.c reiserfs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_REISERFS=1 \ -DNO_BLOCK_FILES=1 -reiserfs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_REISERFS=1 \ +reiserfs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_REISERFS=1 \ -DNO_BLOCK_FILES=1 reiserfs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -171,7 +171,7 @@ disk_io.c stage1_5.c fsys_vstafs.c bios.c vstafs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_VSTAFS=1 \ -DNO_BLOCK_FILES=1 -vstafs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_VSTAFS=1 \ +vstafs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_VSTAFS=1 \ -DNO_BLOCK_FILES=1 vstafs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -180,7 +180,7 @@ disk_io.c stage1_5.c fsys_jfs.c bios.c jfs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_JFS=1 \ -DNO_BLOCK_FILES=1 -jfs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_JFS=1 \
Re: [kkreamer@etherhogz.org: Bug#195234: grub: FTBFS with gcc-3.3]
On Mon, 2003-06-02 at 00:36, Jason Thomas wrote: oukji, is this the correct fix? There's already a (slightly different) fix for this in CVS Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [schizo@debian.org: Re: sed or grub-install bug?]
On Tue, 2003-02-18 at 22:20, Yoshinori K. Okuji wrote: At Wed, 19 Feb 2003 10:29:59 +1100, Jason Thomas wrote: +++ sed -n 's%.*- %\1%p' It's a grub bug. The offending line is: tmp_new_fname=`ls -al $tmp_fname | sed -n 's%.*- %\1%p'` I believe that this should be tmp_new_fname=`readlink $tmp_fname` So, what is the bug? Generally speaking, if you don't tell me what wrong thing happens actually, I wouldn't change anything. I'm guessing that something changed in ls's output so that that sed expression won't work on the output of ls anymore. Sadly, I don't think that readlink is a standard command you can count on the existence of :/ Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [grub #14] message to end edit misleading
On Thu, 2003-01-02 at 09:47, Yoshinori K. Okuji wrote:
At 01 Jan 2003 17:46:32 -0500,
Jeremy Katz wrote:
you're currently editing. Essentially, instead of having
print_cmdline_message take 0 or 1, the parameter would be more of a mode
flag of forever (current forever=1), normal cmdline mode (current
forever=0), and the new one where you hit esc to exit the command line
or enter to accept your changes.
That sounds reasonable. If you implement that, I'll apply.
How does this look?
Jeremy
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.543
diff -u -r1.543 ChangeLog
--- ChangeLog 4 Jan 2003 23:22:42 - 1.543
+++ ChangeLog 6 Jan 2003 05:33:33 -
@@ -1,3 +1,13 @@
+2003-01-06 Jeremy Katz [EMAIL PROTECTED]
+
+ * stage2/cmdline.c (print_cmdline_message): Make the message
+ clearer on what to do when editing an entry in cmdline mode.
+ (enter_cmdline): Use new print_cmdline_message args.
+ * stage2/stage2.c (run_menu): Likewise.
+ * stage2/shared.h (CMDLINE_FOREVER_MODE): Defined.
+ (CMDLINE_NORMAL_MODE): Likewise.
+ (CMDLINE_EDIT_MODE): Likewise.
+
2003-01-05 Yoshinori K. Okuji [EMAIL PROTECTED]
* configure.in (CFLAGS): When the default CFLAGS is used,
Index: stage2/cmdline.c
===
RCS file: /cvsroot/grub/grub/stage2/cmdline.c,v
retrieving revision 1.27
diff -u -r1.27 cmdline.c
--- stage2/cmdline.c 3 Dec 2002 00:02:53 - 1.27
+++ stage2/cmdline.c 6 Jan 2003 05:33:33 -
@@ -48,12 +48,17 @@
/* Print a helpful message for the command-line interface. */
void
-print_cmdline_message (int forever)
+print_cmdline_message (int type)
{
printf ( [ Minimal BASH-like line editing is supported. For the first word, TAB\n
lists possible command completions. Anywhere else TAB lists the possible\n
- completions of a device/filename.%s ]\n,
- (forever ? : ESC at any time exits.));
+ completions of a device/filename.);
+ if (type == CMDLINE_NORMAL_MODE)
+printf( ESC at any time exits.);
+ if (type == CMDLINE_EDIT_MODE)
+printf( ESC at any time cancels. ENTER \n
+ at any time accepts your changes.);
+ printf(]\n);
}
/* Find the builtin whose command name is COMMAND and return the
@@ -128,7 +133,7 @@
print_network_configuration ();
grub_putchar ('\n');
#endif
- print_cmdline_message (forever);
+ print_cmdline_message (forever ? CMDLINE_FOREVER_MODE : CMDLINE_NORMAL_MODE);
while (1)
{
Index: stage2/shared.h
===
RCS file: /cvsroot/grub/grub/stage2/shared.h,v
retrieving revision 1.90
diff -u -r1.90 shared.h
--- stage2/shared.h 3 Dec 2002 00:02:53 - 1.90
+++ stage2/shared.h 6 Jan 2003 05:33:33 -
@@ -843,9 +843,15 @@
void init_config (void);
char *skip_to (int after_equal, char *cmdline);
struct builtin *find_command (char *command);
-void print_cmdline_message (int forever);
void enter_cmdline (char *heap, int forever);
int run_script (char *script, char *heap);
+
+/* the flags for the cmdline message */
+#define CMDLINE_FOREVER_MODE 0x0
+#define CMDLINE_NORMAL_MODE 0x1
+#define CMDLINE_EDIT_MODE 0x2
+
+void print_cmdline_message (int type);
#endif
/* C library replacement functions with identical semantics. */
Index: stage2/stage2.c
===
RCS file: /cvsroot/grub/grub/stage2/stage2.c,v
retrieving revision 1.42
diff -u -r1.42 stage2.c
--- stage2/stage2.c 4 Dec 2002 00:55:45 - 1.42
+++ stage2/stage2.c 6 Jan 2003 05:33:33 -
@@ -655,7 +655,7 @@
else
{
cls ();
- print_cmdline_message (0);
+ print_cmdline_message (CMDLINE_EDIT_MODE);
new_heap = heap + NEW_HEAPSIZE + 1;
___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
Re: automake 1.6 problem.
On Wed, 2003-01-08 at 19:33, Jason Thomas wrote: Hi all, anyone have ideas on what todo about this its on debian unstable with automake 1.6.3: The attached patch makes it build fine for me with automake 1.6, but Okuji has expressed a desire to stay with 1.5 at present. Jeremy diff -ur grub-0.92/configure.in grub/configure.in --- grub-0.92/configure.in Wed May 1 20:54:16 2002 +++ grub/configure.in Wed May 1 20:55:39 2002 @@ -55,8 +55,8 @@ _AM_DEPENDENCIES(CC) dnl Because recent automake complains about AS, set it here. -AS=$CC -AC_SUBST(AS) +CCAS=$CC +AC_SUBST(CCAS) AC_ARG_WITH(binutils, [ --with-binutils=DIR search the directory DIR to find binutils]) @@ -607,9 +607,9 @@ AC_SUBST(NET_EXTRAFLAGS) AC_SUBST(NETBOOT_DRIVERS) -dnl Because recent automake complains about ASFLAGS, set it here. -ASFLAGS='$(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)' -AC_SUBST(ASFLAGS) +dnl Because recent automake complains about CCASFLAGS, set it here. +CCASFLAGS='$(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)' +AC_SUBST(CCASFLAGS) AC_ARG_ENABLE(vga16, [ --disable-vga16disable VGA graphics interface]) diff -ur grub-0.92/stage1/Makefile.am grub/stage1/Makefile.am --- grub-0.92/stage1/Makefile.am Wed Jul 4 03:33:48 2001 +++ grub/stage1/Makefile.am Wed May 1 20:56:58 2002 @@ -4,7 +4,7 @@ CLEANFILES = $(nodist_pkgdata_DATA) # We can't use builtins or standard includes. -AM_ASFLAGS = $(STAGE1_CFLAGS) -fno-builtin -nostdinc +AM_CCASFLAGS = $(STAGE1_CFLAGS) -fno-builtin -nostdinc LDFLAGS = -nostdlib -Wl,-N,-Ttext,7C00 noinst_PROGRAMS = stage1.exec Only in grub/stage1: Makefile.am~ diff -ur grub-0.92/stage2/Makefile.am grub/stage2/Makefile.am --- grub-0.92/stage2/Makefile.am Sun Feb 3 23:55:48 2002 +++ grub/stage2/Makefile.am Wed May 1 20:57:51 2002 @@ -87,7 +87,7 @@ fsys_vstafs.c fsys_xfs.c hercules.c serial.c smp-imps.c \ stage2.c md5.c pre_stage2_exec_CFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) -pre_stage2_exec_ASFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) +pre_stage2_exec_CCASFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) pre_stage2_exec_LDFLAGS = $(PRE_STAGE2_LINK) if NETBOOT_SUPPORT @@ -108,7 +108,7 @@ echo #define STAGE2_SIZE $$6 stage2_size.h start_exec_SOURCES = start.S -start_exec_ASFLAGS = $(STAGE2_COMPILE) +start_exec_CCASFLAGS = $(STAGE2_COMPILE) start_exec_LDFLAGS = $(START_LINK) # XXX: automake doesn't provide a way to specify dependencies for object @@ -126,7 +126,7 @@ stage1_5.c fsys_ext2fs.c bios.c e2fs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ -DNO_BLOCK_FILES=1 -e2fs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ +e2fs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ -DNO_BLOCK_FILES=1 e2fs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -135,7 +135,7 @@ stage1_5.c fsys_fat.c bios.c fat_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FAT=1 \ -DNO_BLOCK_FILES=1 -fat_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FAT=1 \ +fat_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FAT=1 \ -DNO_BLOCK_FILES=1 fat_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -144,7 +144,7 @@ stage1_5.c fsys_ffs.c bios.c ffs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FFS=1 \ -DNO_BLOCK_FILES=1 -ffs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FFS=1 \ +ffs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_FFS=1 \ -DNO_BLOCK_FILES=1 ffs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -153,7 +153,7 @@ stage1_5.c fsys_minix.c bios.c minix_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_MINIX=1 \ -DNO_BLOCK_FILES=1 -minix_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_MINIX=1 \ +minix_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_MINIX=1 \ -DNO_BLOCK_FILES=1 minix_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -162,7 +162,7 @@ disk_io.c stage1_5.c fsys_reiserfs.c bios.c reiserfs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_REISERFS=1 \ -DNO_BLOCK_FILES=1 -reiserfs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_REISERFS=1 \ +reiserfs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_REISERFS=1 \ -DNO_BLOCK_FILES=1 reiserfs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -171,7 +171,7 @@ disk_io.c stage1_5.c fsys_vstafs.c bios.c vstafs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_VSTAFS=1 \ -DNO_BLOCK_FILES=1 -vstafs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_VSTAFS=1 \ +vstafs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_VSTAFS=1 \ -DNO_BLOCK_FILES=1 vstafs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -180,7 +180,7 @@ disk_io.c stage1_5.c fsys_jfs.c bios.c jfs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_JFS=1 \ -DNO_BLOCK_FILES=1 -jfs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_JFS=1 \ +jfs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_JFS=1 \ -DNO_BLOCK_FILES=1 jfs_stage1_5_exec_LDFLAGS = $(STAGE1_5_LINK) @@ -189,7 +189,7 @@ disk_io.c stage1_5.c fsys_xfs.c bios.c
Re: [PATCH] Add support for building on x86_64
On Wed, 2003-01-01 at 10:16, Yoshinori K. Okuji wrote: At 29 Dec 2002 02:29:48 -0500, Jeremy Katz wrote: The attached patch lets GRUB build on x86_64 assuming you have a multilib compatible build environment set up (ie, gcc -m32 gives you 32-bit binaries) I don't know much about x86-64. Does it work in the same way as IA-32 until 64-bit mode is enabled? The processor natively supports running 64-bit and 32-bit code at the same time. To the point that you can install a 32-bit OS (ie, you can install a standard Debian or Red Hat Linux) or you can install a 64-bit OS. It's the latter case that this patch is needed for, so that you can build the boot loader; in the former, host_cpu won't be x86_64, it will just be ix86. Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: RFC: message= type functionality
On Wed, 2003-01-01 at 10:08, Yoshinori K. Okuji wrote: At 29 Dec 2002 01:34:00 -0500, Jeremy Katz wrote: I've had a request for functionality in GRUB similar to lilo's message= directive. This allows sites to have a message file which they then display on boot for various warnings or information about the machine in question. Is this something that sounds reasonable for inclusion? Where would GRUB display a message? Please decide how to design it first. That's the big question I have as well -- I think that their thought was before the menu, but I don't really see how that's going to fit in the available real estate very well. Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Grub splashimage (yes me again)
*/
+},
+#endif /* SUPPORT_GRAPHICS */
/* This must be the last entry. */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }
};
@@ -1039,13 +1065,15 @@
the following grub_printf call will print newlines. */
count_lines = -1;
+ grub_printf(\n);
if (current_term-setcolorstate)
current_term-setcolorstate (COLOR_STATE_HIGHLIGHT);
- grub_printf (\n[Hit return to continue]);
+ grub_printf ([Hit return to continue]);
if (current_term-setcolorstate)
current_term-setcolorstate (COLOR_STATE_NORMAL);
+
do
{
@@ -1083,7 +,7 @@
cls (void)
{
/* If the terminal is dumb, there is no way to clean the terminal. */
- if (current_term-flags TERM_DUMB)
+ if (current_term-flags TERM_DUMB)
grub_putchar ('\n');
else
current_term-cls ();
@@ -1207,6 +1235,16 @@
return ! errnum;
}
+void
+grub_memcpy(void *dest, const void *src, int len)
+{
+ int i;
+ register char *d = (char*)dest, *s = (char*)src;
+
+ for (i = 0; i len; i++)
+d[i] = s[i];
+}
+
void *
grub_memmove (void *to, const void *from, int len)
{
--- /dev/null 2002-10-04 14:48:04.0 -0400
+++ grub-0.93/stage2/graphics.c 2002-12-28 23:37:03.0 -0500
@@ -0,0 +1,552 @@
+/* graphics.c - graphics mode support for GRUB */
+/* Implemented as a terminal type by Jeremy Katz [EMAIL PROTECTED] based
+ * on a patch by Paulo César Pereira de Andrade [EMAIL PROTECTED]
+ */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2001,2002 Red Hat, Inc.
+ * Portions copyright (C) 2000 Conectiva, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+
+
+#ifdef SUPPORT_GRAPHICS
+
+#include term.h
+#include shared.h
+#include graphics.h
+
+int saved_videomode;
+unsigned char *font8x16;
+
+int graphics_inited = 0;
+static char splashimage[64];
+
+#define VSHADOW VSHADOW1
+unsigned char VSHADOW1[38400];
+unsigned char VSHADOW2[38400];
+unsigned char VSHADOW4[38400];
+unsigned char VSHADOW8[38400];
+
+/* constants to define the viewable area */
+const int x0 = 0;
+const int x1 = 80;
+const int y0 = 0;
+const int y1 = 30;
+
+/* text buffer has to be kept around so that we can write things as we
+ * scroll and the like */
+unsigned short text[80 * 30];
+
+/* why do these have to be kept here? */
+int foreground = (63 16) | (63 8) | (63), background = 0, border = 0;
+
+/* current position */
+static int fontx = 0;
+static int fonty = 0;
+
+/* global state so that we don't try to recursively scroll or cursor */
+static int no_scroll = 0;
+
+/* color state */
+static int graphics_standard_color = A_NORMAL;
+static int graphics_normal_color = A_NORMAL;
+static int graphics_highlight_color = A_REVERSE;
+static int graphics_current_color = A_NORMAL;
+static color_state graphics_color_state = COLOR_STATE_STANDARD;
+
+
+/* graphics local functions */
+static void graphics_setxy(int col, int row);
+static void graphics_scroll();
+
+/* FIXME: where do these really belong? */
+static inline void outb(unsigned short port, unsigned char val)
+{
+__asm __volatile (outb %0,%1::a (val), d (port));
+}
+
+static void MapMask(int value) {
+outb(0x3c4, 2);
+outb(0x3c5, value);
+}
+
+/* bit mask register */
+static void BitMask(int value) {
+outb(0x3ce, 8);
+outb(0x3cf, value);
+}
+
+
+
+/* Set the splash image */
+void graphics_set_splash(char *splashfile) {
+grub_strcpy(splashimage, splashfile);
+}
+
+/* Get the current splash image */
+char *graphics_get_splash(void) {
+return splashimage;
+}
+
+/* Initialize a vga16 graphics display with the palette based off of
+ * the image in splashimage. If the image doesn't exist, leave graphics
+ * mode. */
+int graphics_init()
+{
+if (!graphics_inited) {
+saved_videomode = set_videomode(0x12);
+}
+
+if (!read_image(splashimage)) {
+set_videomode(saved_videomode);
+grub_printf(failed to read image\n);
+return 0;
+}
+
+font8x16 = (unsigned char*)graphics_get_font();
+
+graphics_inited = 1;
+
+/* make sure that the highlight color is set correctly */
+graphics_highlight_color = ((graphics_normal_color 4
[PATCH] Add support for building on x86_64
The attached patch lets GRUB build on x86_64 assuming you have a multilib compatible build environment set up (ie, gcc -m32 gives you 32-bit binaries) Jeremy Index: ChangeLog === RCS file: /cvsroot/grub/grub/ChangeLog,v retrieving revision 1.540 diff -u -u -r1.540 ChangeLog --- ChangeLog 21 Dec 2002 00:34:33 - 1.540 +++ ChangeLog 29 Dec 2002 07:28:39 - @@ -1,3 +1,7 @@ +2002-12-29 Jeremy Katz [EMAIL PROTECTED] + + * configure.in: Support building on x86_64 with gcc -m32. + 2002-12-21 Yoshinori K. Okuji [EMAIL PROTECTED] * stage2/asm.S (gateA20): First, try a BIOS call (INT 15H, Index: configure.in === RCS file: /cvsroot/grub/grub/configure.in,v retrieving revision 1.74 diff -u -u -r1.74 configure.in --- configure.in 29 Nov 2002 20:39:23 - 1.74 +++ configure.in 29 Dec 2002 07:28:40 - @@ -21,6 +21,7 @@ case $host_cpu in i[[3456]]86) host_cpu=i386 ;; +x86_64) host_cpu=x86_64 ;; *) AC_MSG_ERROR([unsupported CPU type]) ;; esac @@ -44,6 +45,12 @@ default_CFLAGS=yes fi +# this should be checked before AC_PROG_CC +if test x$host_cpu = xx86_64; then + CFLAGS=-m32 $CFLAGS +fi + + # # Programs # @@ -72,7 +79,7 @@ # optimization flags if test x$ac_cv_prog_gcc = xyes; then if test x$default_CFLAGS = xyes; then -CFLAGS=-g +CFLAGS=$CFLAGS -g # If the user specify the directory for binutils, add the option `-B'. if test x$with_binutils != x; then CFLAGS=-B$with_binutils/ $CFLAGS ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: question about grub 0.92
On Sat, 2002-10-19 at 09:05, Roman Jordan wrote: Hi, i downloaded grub version 0.92. And i found no information about the splash image. I use at the moment grub version 0.91. If i there call info grub i found one sentences about splash image. My question now: Is a splash image usable in version 0.92? And if so, are there the same limitations (640x480, 14 bit)? The splash image support is not included in the main grub sources and is only included in patches distributed by several vendors. The limitations for the image are still 640x480 with no more than 16 colors as the vga16 video mode is being used. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Bug-grub] [PATCH] Allow appending kernel options directly fromthe main menu
Because I didn't write it and I'm not going to spend a lot of time reorganizing working code without a good reason? :) I'm also not convinced that consolidation with 'e' would do much to help things -- most of the code for the 'a' case is to handle actually going past the kernel and just displaying the arguments for editing as opposed to showing the whole line. The shared code is largely allocating the new_heap and finding the config entry, but similar bits are already duplicated in most of the cases of run_menu() just due to the slight variations needed for each one. Cheers, Jeremy On Tue, 2002-10-01 at 17:52, Jason Thomas wrote: if this is almost the same as 'e' than why all the duplication? On Tue, Oct 01, 2002 at 05:16:11PM -0400, Jeremy Katz wrote: The following patch lets users to directly edit the kernel command line by pressing 'a' at the grub menu. This makes it significantly easier for users to do things such as boot in single user mode or pass kernel options for debugging. Patch is against current CVS. ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCH] Switch to non-deprecated compiler options
On Wed, 2002-10-02 at 00:30, Yoshinori K. Okuji wrote:
At 01 Oct 2002 17:16:06 -0400,
Jeremy Katz wrote:
The use of -m flags for align-jumps, align-loops, and align-functions is
deprecated in gcc 3.2 The following patch switches to the supported
options of -falign-jumps, -falign-loops, and -falign-functions
respectively.
Since when have -falign-{jumps,loops,functions} been supported? IIRC,
they are not supported by gcc 2.x, not even by 2.95.3. So I don't
think it would be a Good Thing to just switch to them. Instead, you
should check if the compiler accepts them in the configure script.
Whoops, sorry -- I didn't have a copy of 2.95.3 installed and my
timescale for the age of 2.95 was off a bit when I checked in the gcc
changelog.
The following patch should do the check and then use the -f variant if
it exists, falling back to the -m variant if not.
Cheers,
Jeremy
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.522
diff -u -u -r1.522 ChangeLog
--- ChangeLog 13 Sep 2002 11:49:56 - 1.522
+++ ChangeLog 2 Oct 2002 20:44:53 -
@@ -1,3 +1,9 @@
+2002-10-02 Jeremy Katz [EMAIL PROTECTED]
+
+ * configure.in (CPPFLAGS): Check if -falign-jumps, -falign-loops,
+ and -falign-functions exist to use instead of deprecated machine
+ dependent versions.
+
2002-09-13 Yoshinori K. Okuji [EMAIL PROTECTED]
* stage2/serial.c (fill_input_buf): Take a new argument NOWAIT.
Index: configure.in
===
RCS file: /cvsroot/grub/grub/configure.in,v
retrieving revision 1.72
diff -u -u -r1.72 configure.in
--- configure.in8 Sep 2002 02:01:14 - 1.72
+++ configure.in2 Oct 2002 20:44:54 -
@@ -108,11 +108,42 @@
CPPFLAGS=$saved_CPPFLAGS
])
-# Force no alignment to save space.
-CPPFLAGS=$CPPFLAGS -malign-jumps=1 -malign-loops=1 -malign-functions=1
-
if test x$undef_flag = xyes; then
CPPFLAGS=$CPPFLAGS -Wundef
+fi
+
+# Force no alignment to save space.
+AC_CACHE_CHECK([whether -falign-loops works], falignloop_flag, [
+ saved_CPPFLAGS=$CPPFLAGS
+ CPPFLAGS=-falign-loops=1
+ AC_TRY_COMPILE(, , falignloop_flag=yes, falignloop_flag=no)
+ CPPFLAGS=$saved_CPPFLAGS
+])
+
+if test x$falignloop_flag = xyes; then
+ CPPFLAGS=$CPPFLAGS -falign-loops=1
+fi
+
+AC_CACHE_CHECK([whether -falign-functions works], falignfunction_flag, [
+ saved_CPPFLAGS=$CPPFLAGS
+ CPPFLAGS=-falign-functions=1
+ AC_TRY_COMPILE(, , falignfunction_flag=yes, falignfunction_flag=no)
+ CPPFLAGS=$saved_CPPFLAGS
+])
+
+if test x$falignfunction_flag = xyes; then
+ CPPFLAGS=$CPPFLAGS -falign-functions=1
+fi
+
+AC_CACHE_CHECK([whether -falign-jumps works], falignjump_flag, [
+ saved_CPPFLAGS=$CPPFLAGS
+ CPPFLAGS=-falign-jumps=1
+ AC_TRY_COMPILE(, , falignjump_flag=yes, falignjump_flag=no)
+ CPPFLAGS=$saved_CPPFLAGS
+])
+
+if test x$falignjump_flag = xyes; then
+ CPPFLAGS=$CPPFLAGS -falign-jumps=1
fi
if test x$with_binutils != x; then
___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] Switch to non-deprecated compiler options
The use of -m flags for align-jumps, align-loops, and align-functions is deprecated in gcc 3.2 The following patch switches to the supported options of -falign-jumps, -falign-loops, and -falign-functions respectively. Cheers, Jeremy Index: ChangeLog === RCS file: /cvsroot/grub/grub/ChangeLog,v retrieving revision 1.522 diff -u -r1.522 ChangeLog --- ChangeLog 13 Sep 2002 11:49:56 - 1.522 +++ ChangeLog 1 Oct 2002 21:11:40 - @@ -1,3 +1,7 @@ +2002-10-01 Jeremy Katz [EMAIL PROTECTED] + + * configure.in (CPPFLAGS): Don't use deprecated compiler options. + 2002-09-13 Yoshinori K. Okuji [EMAIL PROTECTED] * stage2/serial.c (fill_input_buf): Take a new argument NOWAIT. Index: configure.in === RCS file: /cvsroot/grub/grub/configure.in,v retrieving revision 1.72 diff -u -r1.72 configure.in --- configure.in8 Sep 2002 02:01:14 - 1.72 +++ configure.in1 Oct 2002 21:11:41 - @@ -109,7 +109,7 @@ ]) # Force no alignment to save space. -CPPFLAGS=$CPPFLAGS -malign-jumps=1 -malign-loops=1 -malign-functions=1 +CPPFLAGS=$CPPFLAGS -falign-jumps=1 -falign-loops=1 -falign-functions=1 if test x$undef_flag = xyes; then CPPFLAGS=$CPPFLAGS -Wundef ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] Fixups to work with automake 1.6
automake 1.6 has AS and ASFLAGS as reserved variables used internally. The following patch changes them to CCAS and CCASFLAGS per the autotools documentation. Cheers, Jeremy Index: ChangeLog === RCS file: /cvsroot/grub/grub/ChangeLog,v retrieving revision 1.522 diff -u -r1.522 ChangeLog --- ChangeLog 13 Sep 2002 11:49:56 - 1.522 +++ ChangeLog 1 Oct 2002 21:09:31 - @@ -1,3 +1,38 @@ +2002-10-01 Jeremy Katz [EMAIL PROTECTED] + + * stage2/Makefile.am (pre_stage2_exec_ASFLAGS): Renamed to ... + (pre_stage2_exec_CCASFLAGS): ... this. + (e2fs_stage1_5_exec_ASFLAGS): Renamed to ... + (e2fs_stage1_5_exec_CCASFLAGS): ... this. + (fat_stage1_5_exec_ASFLAGS): Renamed to ... + (fat_stage1_5_exec_CCASFLAGS): ... this. + (ffs_stage1_5_exec_ASFLAGS): Renamed to ... + (ffs_stage1_5_exec_CCASFLAGS): ... this. + (minix_stage1_5_exec_ASFLAGS): Renamed to ... + (minix_stage1_5_exec_CCASFLAGS): ... this. + (reiserfs_stage1_5_exec_ASFLAGS): Renamed to ... + (reiserfs_stage1_5_exec_CCASFLAGS): ... this. + (vstatfs_stage1_5_exec_ASFLAGS): Renamed to ... + (vstatfs_stage1_5_exec_CCASFLAGS): ... this. + (jfs_stage1_5_exec_ASFLAGS): Renamed to ... + (jfs_stage1_5_exec_CCASFLAGS): ... this. + (xfs_stage1_5_exec_ASFLAGS): Renamed to ... + (xfs_stage1_5_exec_CCASFLAGS): ... this. + (diskless_exec_ASFLAGS): Renamed to ... + (diskless_exec_CCASFLAGS): ... this. + (nbloader_exec_ASFLAGS): Renamed to ... + (nbloader_exec_CCASFLAGS): ... this. + (pxeloader_exec_ASFLAGS): Renamed to ... + (pxeloader_exec_CCASFLAGS): ... this. + + * stage1/Makefile.am (AM_ASFLAGS): Renamed to ... + (AM_CCASFLAGS): ... this. + + * configure.in (ASFLAGS): Renamed to ... + (CCASFLAGS): ... this due to automake 1.6 reserved variable. + (AS): Renamed to ... + (CCAS): ... this due to automake 1.6 reserved variable. + 2002-09-13 Yoshinori K. Okuji [EMAIL PROTECTED] * stage2/serial.c (fill_input_buf): Take a new argument NOWAIT. Index: configure.in === RCS file: /cvsroot/grub/grub/configure.in,v retrieving revision 1.72 diff -u -r1.72 configure.in --- configure.in8 Sep 2002 02:01:14 - 1.72 +++ configure.in1 Oct 2002 21:09:31 - @@ -54,8 +54,8 @@ _AM_DEPENDENCIES(CC) dnl Because recent automake complains about AS, set it here. -AS=$CC -AC_SUBST(AS) +CCAS=$CC +AC_SUBST(CCAS) AC_ARG_WITH(binutils, [ --with-binutils=DIR search the directory DIR to find binutils]) @@ -606,9 +606,9 @@ AC_SUBST(NET_EXTRAFLAGS) AC_SUBST(NETBOOT_DRIVERS) -dnl Because recent automake complains about ASFLAGS, set it here. -ASFLAGS='$(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)' -AC_SUBST(ASFLAGS) +dnl Because recent automake complains about CCASFLAGS, set it here. +CCASFLAGS='$(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)' +AC_SUBST(CCASFLAGS) dnl Output. Index: stage1/Makefile.am === RCS file: /cvsroot/grub/grub/stage1/Makefile.am,v retrieving revision 1.14 diff -u -r1.14 Makefile.am --- stage1/Makefile.am 4 Jul 2001 07:33:48 - 1.14 +++ stage1/Makefile.am 1 Oct 2002 21:09:31 - @@ -4,7 +4,7 @@ CLEANFILES = $(nodist_pkgdata_DATA) # We can't use builtins or standard includes. -AM_ASFLAGS = $(STAGE1_CFLAGS) -fno-builtin -nostdinc +AM_CCASFLAGS = $(STAGE1_CFLAGS) -fno-builtin -nostdinc LDFLAGS = -nostdlib -Wl,-N,-Ttext,7C00 noinst_PROGRAMS = stage1.exec Index: stage2/Makefile.am === RCS file: /cvsroot/grub/grub/stage2/Makefile.am,v retrieving revision 1.39 diff -u -r1.39 Makefile.am --- stage2/Makefile.am 11 Jun 2002 16:36:54 - 1.39 +++ stage2/Makefile.am 1 Oct 2002 21:09:31 - @@ -88,7 +88,7 @@ fsys_vstafs.c fsys_xfs.c gunzip.c hercules.c md5.c serial.c \ smp-imps.c stage2.c pre_stage2_exec_CFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) -pre_stage2_exec_ASFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) +pre_stage2_exec_CCASFLAGS = $(STAGE2_COMPILE) $(FSYS_CFLAGS) pre_stage2_exec_LDFLAGS = $(PRE_STAGE2_LINK) if NETBOOT_SUPPORT @@ -109,7 +109,7 @@ echo #define STAGE2_SIZE $$6 stage2_size.h start_exec_SOURCES = start.S -start_exec_ASFLAGS = $(STAGE2_COMPILE) +start_exec_CCASFLAGS = $(STAGE2_COMPILE) start_exec_LDFLAGS = $(START_LINK) # XXX: automake doesn't provide a way to specify dependencies for object @@ -127,7 +127,7 @@ stage1_5.c fsys_ext2fs.c bios.c e2fs_stage1_5_exec_CFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ -DNO_BLOCK_FILES=1 -e2fs_stage1_5_exec_ASFLAGS = $(STAGE1_5_COMPILE) -DFSYS_EXT2FS=1 \ +e2fs_stage1_5_exec_CCASFLAGS = $(STAGE1_5_COMPILE
[PATCH] Allow appending kernel options directly from the main menu
The following patch lets users to directly edit the kernel command line
by pressing 'a' at the grub menu. This makes it significantly easier
for users to do things such as boot in single user mode or pass kernel
options for debugging.
Patch is against current CVS.
Cheers,
Jeremy
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.522
diff -u -r1.522 ChangeLog
--- ChangeLog 13 Sep 2002 11:49:56 - 1.522
+++ ChangeLog 1 Oct 2002 20:48:57 -
@@ -1,3 +1,9 @@
+2002-10-01 Jeremy Katz [EMAIL PROTECTED]
+
+ From Erik Troan [EMAIL PROTECTED]:
+ * stage2/stage2.c (run_menu): Add support for appending options to
+ kernel lines and booting directly with those changes.
+
2002-09-13 Yoshinori K. Okuji [EMAIL PROTECTED]
* stage2/serial.c (fill_input_buf): Take a new argument NOWAIT.
Index: stage2/stage2.c
===
RCS file: /cvsroot/grub/grub/stage2/stage2.c,v
retrieving revision 1.38
diff -u -r1.38 stage2.c
--- stage2/stage2.c 22 Aug 2002 05:59:55 - 1.38
+++ stage2/stage2.c 1 Oct 2002 20:48:58 -
@@ -314,7 +314,8 @@
if (config_entries)
printf (\
Press enter to boot the selected OS, \'e\' to edit the\n\
- commands before booting, or \'c\' for a command-line.);
+ commands before booting, \'a\' to modify the kernel arguments\n\
+ before booting, or \'c\' for a command-line.);
else
printf (\
Press \'b\' to boot, \'e\' to edit the selected command in the\n\
@@ -665,6 +666,98 @@
{
enter_cmdline (heap, 0);
goto restart;
+ }
+ if (config_entries c == 'a')
+ {
+ int new_num_entries = 0, i = 0, j;
+ int needs_padding, amount;
+ char *new_heap;
+ char * entries;
+ char * entry_copy;
+ char * append_line;
+ char * start;
+
+ entry_copy = new_heap = heap;
+ cur_entry = get_entry (config_entries, first_entry + entryno,
+1);
+
+ do
+ {
+ while ((*(new_heap++) = cur_entry[i++]) != 0);
+ new_num_entries++;
+ }
+ while (config_entries cur_entry[i]);
+
+ /* this only needs to be done if config_entries is non-NULL,
+but it doesn't hurt to do it always */
+ *(new_heap++) = 0;
+
+ new_heap = heap + NEW_HEAPSIZE + 1;
+
+ entries = entry_copy;
+ while (*entries)
+ {
+ if ((strstr(entries, kernel) == entries)
+ isspace(entries[6]))
+ break;
+
+ while (*entries) entries++;
+ entries++;
+ }
+
+ if (!*entries)
+ goto restart;
+
+ start = entries + 6;
+
+ /* skip the white space */
+ while (*start isspace(*start)) start++;
+ /* skip the kernel name */
+ while (*start !isspace(*start)) start++;
+
+ /* skip the white space */
+ needs_padding = (!*start || !isspace(*start));
+ while (*start isspace(*start)) start++;
+
+ append_line = new_heap;
+ grub_strcpy(append_line, start);
+
+ cls();
+ print_cmdline_message (0);
+
+ if (get_cmdline(PACKAGE append ,
+ append_line, NEW_HEAPSIZE + 1,
+ 0, 1))
+ goto restart;
+
+ /* have new args; append_line points to the
+new args and start points to the old
+args */
+
+ i = grub_strlen(start);
+ j = grub_strlen(append_line);
+
+ if (i (j + needs_padding))
+ amount = i;
+ else
+ amount = j + needs_padding;
+
+ /* align rest of commands properly */
+ memmove (start + j + needs_padding, start + i,
+ ((int) append_line) - ((int) start) - (amount));
+
+ if (needs_padding)
+ *start = ' ';
+
+ /* copy command to correct area */
+ memmove (start + needs_padding, append_line, j);
+
+ /* set up this entry to boot */
+ config_entries = NULL;
+ cur_entry = entry_copy;
+ heap = new_heap;
+
+ break
Re: Problems with Compaq DL380G2 running Redhat 7.2
On Thu, 2002-05-30 at 05:21, Yeo Eng Hee wrote: Everything worked fine until I had to compile and install my own kernel. (I needed to run Linux 2.4.22 kernel to access the hot-plug tape that comes with the DL380G2). 2.4.22? Do you mean 2.2.22? I tried configuring grub using new-kernel-pkg and grubby, but when I reboot, I got a kernel panic with a message saying the my root fs is not mounted, cciss/c0d0p1 not valid and to set root= properly (I am writing this from memory). Did you include the cciss module in your kernel? Or, alternately, if you built it as a module, did you make a new initrd? Another disaster is when I tried to run grub-install, and got an error message: # grub-install '(hd0)' /dev/cciss/c0d0p1 does not have any corresponding BIOS drive. It looks like the grub-install bits to do the right thing with the SmartArray broke again. Just to verify, what were the contents of your /boot/grub/device.map? Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Problems with Compaq DL380G2 running Redhat 7.2
On Thu, 2002-05-30 at 14:01, Thierry Laronde wrote: On Thu, May 30, 2002 at 05:21:43PM +0800, Yeo Eng Hee wrote: I am encountering a problem with the bootloader. Everything worked fine until I had to compile and install my own kernel. (I needed to run Linux 2.4.22 kernel to access the hot-plug tape that comes with the DL380G2). I tried configuring grub using new-kernel-pkg and grubby, but when I reboot, I got a kernel panic with a message saying the my root fs is not mounted, cciss/c0d0p1 not valid and to set root= properly (I am writing this from memory). I think some people from RedHat are listening to the list. Because since `new-kernel-pkg' and `grubby' are neither part of the GRUB vanilla or standard on other distributions, it will be difficult to debug without knowing exactly what these utils do... For reference -- new-kernel-pkg is just a script which gets called on the installation of our kernel packages to create an initrd if needed, update modules.dep files, and update the boot loader configuration. grubby is the program which actually handled the updating of the boot loader config, basically by cloning the previous config and changing the file names. For an idea of what they did here, more information on exactly what arguments were passed to each would be needed. For the second time problems, it seems to me that the informations in stage1 have been spoiled by the failed `grub-install'. If, here, only the vanilla `grub-install' has spoiled its data (writing something without being sure to he able to run), there is a bug. But I'm a bit suspicious about this one too. Is the `grub-install' on RedHat modified in order to query from the kernel the root partition (invoquing rdev for example)? Nope, the changes in grub-install are all pretty much cosmetic... we have Erich's patch to add a sync or three and then move the copying into a function instead of just being directly there so that there can be a command line flag just to copy the stage2 bits over from their initial location. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
RE: Problems with Compaq DL380G2 running Redhat 7.2
On Fri, 2002-05-31 at 03:44, Yeo Eng Hee wrote: The main problem I encounter was that grub did not seem to recognise the changes I did to /etc/grub.conf (I edited it manually). This is what I thought would have worked: That's the right thing to do, assuming the kernel config is correct. I have a new option now, which is to upgrade this system to RedHat 7.3, and let the RedHat installer to correct the MBR in the process. Would this be a better idea than to waste time figuring out how to set the MBR manually on the command line? Are you currently just getting the GRUB command line when you boot or are you just getting GRUB and then a hang? If the former, then it should be relatively easy to figure out what's going on without having to reinstall or anything. If the latter, then it's more curious and I would be somewhat interested to know what the current contents of your /boot/grub/device.map file are. You can get to it by booting into rescue mode (see the Red Hat Linux documentation for more information on rescue mode) from which you should be able to get to the file and see if it looks correct. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: use Savannah more aggresisvely
On Wed, 2002-05-29 at 08:30, Florian Hatat wrote: Le mardi 28 mai 2002, Jeremy Katz scripta: I think this is a great thing, personally, especially with the messages being cc'd to bug-grub. This increases a lot the trafic on the list... Not really -- in the past, bug reports would get mailed to the list. Now they will get filed in the BTS and as a consequence get mailed to the list. There's some ramp up where people are putting already known bugs which have already been discussed into the BTS so they can be properly tracked. Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] bootstrapping NT with grub tweak
This was originally reported in Red Hat's bugzilla as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65034 by [EMAIL PROTECTED] To quote the original bug report The version of grub included with RH 7.3 won't boot windows NT 4.0 SP3 on my system. NT boot fails with bluescreen INACCESSIBLE_BOOT_DEVICE. Before upgrade to RH 7.3 my system worked fine as a triple boot setup: /dev/sda1 WinNT; /dev/sda2 Win95; /dev/sda3 RH Linux. Before upgrade system was running RH 7.0 and triple boot with Lilo was working fine. Research on web indicated that WinNT expects bootstrap loader to begin with a CLI instruction. Checking grub sources shows it starts with a JMP followed by a CLI. Solution: Change 1st instruction to a CLI, remove a NOP and JMP to main part of bootstrap code. Rebuild and reinstall grub. Tested on my triple boot system and a normal single boot RH 7.3 system and works. The reporter attached the following patch which says improves the situation for them. Any comments? Thanks, Jeremy --- grub-0.91/stage1/stage1.S.orig Wed May 15 16:51:40 2002 +++ grub-0.91/stage1/stage1.S Wed May 15 16:52:56 2002 @@ -53,8 +53,8 @@ * parameter block. */ + cli /* NT requires this to be the first instruction */ jmp after_BPB - nop /* do I care about this ??? */ /* * This space is for the BIOS parameter block Don't change @@ -105,7 +105,6 @@ after_BPB: /* general setup */ - cli /* we're not safe here! */ /* * ljmp to the next instruction because some bogus BIOSes ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: menu.lst or grub.conf and attributes
On Wed, 2002-04-24 at 22:53, Martin Felker wrote: Will someone please clear up the issue about whether Red Hat Linux uses a GRUB configuration file called menu.lst or grub.conf.I suspect it may be the former as menu.lst appeared to have different attributes (executable??) than the identical file grub.conf when installed from grub.conf for a variety of reasons at this point... menu.lst is created by the installer as a symlink so that people who have past experience with grub and use menu.lst as the filename for editing. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: about the xpm format used by grub
On Thu, 2002-03-28 at 16:16, [EMAIL PROTECTED] wrote: I can't find any tip about the good xpm format to use with grub, seems it needs some special format. Nothing in the mailing lists nor the man or the infodoc, someone can help ??? The splash image patch is not supported by the upstream GRUB maintainers, but the format is a gzipped 640x480 xpm with 16 colors (14 + the foreground and background color defined in your menu.lst/grub.conf file) Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCH] Parse mem= on Linux kernel command line to changeinitrd load address (resend)
On Wed, 2002-03-20 at 03:54, Yoshinori K. Okuji wrote: At 08 Mar 2002 16:50:57 -0500, Jeremy Katz wrote: The attached patch lets GRUB parse a Linux kernel command line for mem= to use as the upper memory location for an initrd as opposed to the maximum detected memory amount per the Linux/I386 boot protocol. Is it really necessary to use simple_strtoul? I know safe_parse_maxint doesn't do the same thing, because it understands the prefix `0x' and the return value is signed, but I suspect that the difference is negligible. What do you think? There'd have to be a different version to handle unsigned longs, though, as you have to be able to handle a memory size of unsigned long (although people don't generally do mem=4294967296, it's perfectly valid to do so) Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Caldera patches
On Wed, 2002-03-13 at 16:59, Sergey Babkin wrote: I've recently ported the Caldera's patches from grub-0.5.96.1 to grub-0.91 and I wonder if the GRUB project would be interested in integrating them back into the main tree. The patches are: To comment on at least a couple of these... grub-0.91-splash.patch - the splashscreen command for a graphical splashscreen Is this based off of the same patch that Conectiva (and now Red Hat) uses? If not, I would be interested in seeing a copy off-list at least. grub-0.91-initrd16M.patch - I'm not sure what exactly it does but it looks like support for a larger RAM disk image This patch is a hack to work around the fact that grub didn't follow mem= and set the maximum location for the initrd loaded to be at 16 megs. I sent a better patch to handle this correctly earlier this week (also available at http://people.redhat.com/~katzj/grub/patches/grub-0.91-initrdusemem.patch) grub-0.91-nomeminfo.patch - by default does not pass the mem= option to the Linux kernel since Linux 2.4 is able to determine the memory size by itself. Again, I'm not sure if it's of general interest. You can accomplish the same effect by passing --disable-auto-linux-mem-opt to configure. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] Parse mem= on Linux kernel command line to change initrdload address (resend)
Sending again with the minor ChangeLog tweak to get it to apply cleanly
against current CVS.
The attached patch lets GRUB parse a Linux kernel command line for mem=
to use as the upper memory location for an initrd as opposed to the
maximum detected memory amount per the Linux/I386 boot protocol.
Jeremy
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.477
diff -u -u -r1.477 ChangeLog
--- ChangeLog 11 Feb 2002 08:10:57 - 1.477
+++ ChangeLog 8 Mar 2002 21:43:01 -
@@ -1,3 +1,13 @@
+2002-03-08 Jeremy Katz [EMAIL PROTECTED]
+
+ * stage2/boot.c (load_image): Look for mem= on Linux kernel
+ command line and set max memory for loading the initrd
+ appropriately.
+ (load_initrd): Likewise.
+ * stage2/char_io.c (simple_strtoul): Simple string to unsigned
+ long function.
+ * stage2/shared.h (simple_strtoul): Defined.
+
2002-02-11 Pavel Roskin [EMAIL PROTECTED]
* util/grub-install.in (find_device): New function - find block
Index: stage2/boot.c
===
RCS file: /cvsroot/grub/grub/stage2/boot.c,v
retrieving revision 1.36
diff -u -u -r1.36 boot.c
--- stage2/boot.c 12 Nov 2001 06:57:29 - 1.36
+++ stage2/boot.c 8 Mar 2002 21:43:01 -
@@ -28,6 +28,7 @@
static int cur_addr;
entry_func entry_addr;
static struct mod_list mll[99];
+static unsigned long kernel_mem_end = 0;
/*
@@ -308,6 +309,36 @@
0,
(64 - setup_sects - 1) 9);
+ /* we need to parse mem= from the command-line so that we can load
+the initrd in the right place. bleah */
+ {
+ char *mem;
+
+ mem = grub_strstr (arg, mem=);
+ if (mem)
+ {
+/* we handle this identically to the kernel; see memparse
+ in lib/cmdline.c of the kernel source for the
+ original location of this code */
+kernel_mem_end = simple_strtoul(mem+4, mem);
+
+switch(*mem)
+ {
+ case 'G':
+ case 'g':
+kernel_mem_end = 10;
+ case 'M':
+ case 'm':
+kernel_mem_end = 10;
+ case 'K':
+ case 'k':
+kernel_mem_end = 10;
+ default:
+break;
+ }
+ }
+ }
+
/* Copy command-line plus memory hack to staging area.
NOTE: Linux has a bug that it doesn't handle multiple spaces
between two options and a space after a mem= option isn't
@@ -720,7 +751,9 @@
goto fail;
}
- moveto = ((mbi.mem_upper + 0x400) * 0x400 - len) 0xf000;
+ if (!kernel_mem_end)
+kernel_mem_end = (mbi.mem_upper + 0x400) * 0x400;
+ moveto = (kernel_mem_end - len) 0xf000;
if (moveto + len = LINUX_INITRD_MAX_ADDRESS)
moveto = (LINUX_INITRD_MAX_ADDRESS - len) 0xf000;
Index: stage2/char_io.c
===
RCS file: /cvsroot/grub/grub/stage2/char_io.c,v
retrieving revision 1.45
diff -u -u -r1.45 char_io.c
--- stage2/char_io.c8 Feb 2002 01:14:01 - 1.45
+++ stage2/char_io.c8 Mar 2002 21:43:01 -
@@ -967,6 +967,34 @@
return 1;
}
+/* convert a string to an unsigned long. basically taken straight from
+ * the Linux kernel (lib/vsprintf.c) but made even simpler due to lack of
+ * base handling
+ * str_ptr is the start of the string,
+ * endp will point to the end of the parsed string when we're done
+ */
+unsigned long
+simple_strtoul(char *str_ptr, char **endp)
+{
+ unsigned long result = 0;
+
+ while (1)
+ {
+ unsigned int digit;
+
+ digit = *str_ptr - '0';
+ /* since digit is unsigned, it will wrap */
+ if (digit 9)
+ break;
+ result = result * 10 + digit;
+ str_ptr++;
+ }
+
+ if (endp)
+ *endp = (char *)str_ptr;
+ return result;
+}
+
int
grub_tolower (int c)
{
Index: stage2/shared.h
===
RCS file: /cvsroot/grub/grub/stage2/shared.h,v
retrieving revision 1.84
diff -u -u -r1.84 shared.h
--- stage2/shared.h 8 Feb 2002 01:14:01 - 1.84
+++ stage2/shared.h 8 Mar 2002 21:43:01 -
@@ -918,6 +918,9 @@
int grub_strlen (const char *str);
char *grub_strcpy (char *dest, const char *src);
+/* simple version of string to unsigned long; doesn't handle bases */
+unsigned long simple_strtoul(char *str_ptr, char **endp);
+
#ifndef GRUB_UTIL
typedef unsigned long grub_jmp_buf[6];
#else
Re: Win98 APM fails w/grub 0.90
On Thu, 2002-02-28 at 17:54, Ed Swierk wrote: I recently upgraded my ThinkPad 600 to RedHat Linux 7.2, which installs grub 0.90 as the bootloader in place of LILO. After that, the APM driver always failed to load when I booted into the existing Windows 98 partition. When I reverted either to LILO or to the standard Windows bootloader, APM worked again. Bug in grub 0.90. Fixed since and updated Red Hat Linux packages with the fix can be found at http://people.redhat.com/~katzj/grub/ Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Possible bug in grub with USB Keyboard
On Tue, 2002-02-26 at 12:38, Derrik Pates wrote: On Tue, Feb 26, 2002 at 04:36:30PM +, Rob wrote: There is a bug, reproducable every time with my hardware cant say for others, grub does not recognise usb keyboard input. No, that's not a GRUB problem. Your BIOS can probably deal on its own with USB devices, but if you booted into DOS, say, you'd be in the same boat - i.e., your keyboard would be invisible to it. You need to turn on legacy keyboard emulation in your BIOS (most recent boards have such an option) for GRUB to be able to see the keyboard - unless you REALLY want to implement a USB stack, USB UHCI and OHCI (and eventually EHCI) controller drivers, and an HID class driver in GRUB, which I think would be an unnecessary pain in the ass. Actually, I have reports from reliable sources (I trust Alan to know how to set up his BIOS :-) that this isn't the case and that even with legacy mode on it doesn't work properly. Same hardware works with no modifications in LILO. None of my test hardware can replicate the problem, unfortunately and from my comparison of LILO and GRUB, there's not an obvious problem. Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: GRUB with second IDE hard disk
On Mon, 2002-02-18 at 18:00, Muralidhar Ganga wrote: I installed a new IDE hard disk. I installed Redhat 7.2 on it and chose to update the GRUB to be installed on MBR. Previsously I had NT and Linux on the first hard drive with with GRUB on the MBR. After successful installation of Redhat 7.2 on second hard disk, I could not see the previous images on the GRUB and I see only the new image. After booting the second hard drive, from the command line I did the following: /sbin/grub-install /dev/hdb (hdb being the second IDE hard disk) It complains about the no corresponding BIOS drive letter found. You need to edit /boot/grub/device.map and add a line like the following (hd1) /dev/hdb Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] Parse mem= on Linux kernel command line to change initrdload address
The attached patch lets GRUB parse a Linux kernel command line for mem=
to use as the upper memory location for an initrd as opposed to the
maximum detected memory amount.
Cheers,
Jeremy
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.476
diff -u -u -r1.476 ChangeLog
--- ChangeLog 8 Feb 2002 01:28:39 - 1.476
+++ ChangeLog 8 Feb 2002 20:08:33 -
@@ -1,3 +1,13 @@
+2002-02-08 Jeremy Katz [EMAIL PROTECTED]
+
+ * stage2/boot.c (load_image): Look for mem= on Linux kernel
+ command line and set max memory for loading the initrd
+ appropriately.
+ (load_initrd): Likewise.
+ * stage2/char_io.c (simple_strtoul): Simple string to unsigned
+ long function.
+ * stage2/shared.h (simple_strtoul): Defined.
+
2002-02-08 Yoshinori K. Okuji [EMAIL PROTECTED]
* grub/main.c (OPT_NO_PAGER): New macro.
Index: stage2/boot.c
===
RCS file: /cvsroot/grub/grub/stage2/boot.c,v
retrieving revision 1.36
diff -u -u -r1.36 boot.c
--- stage2/boot.c 12 Nov 2001 06:57:29 - 1.36
+++ stage2/boot.c 8 Feb 2002 20:08:33 -
@@ -28,6 +28,7 @@
static int cur_addr;
entry_func entry_addr;
static struct mod_list mll[99];
+static unsigned long kernel_mem_end = 0;
/*
@@ -308,6 +309,36 @@
0,
(64 - setup_sects - 1) 9);
+ /* we need to parse mem= from the command-line so that we can load
+the initrd in the right place. bleah */
+ {
+ char *mem;
+
+ mem = grub_strstr (arg, mem=);
+ if (mem)
+ {
+/* we handle this identically to the kernel; see memparse
+ in lib/cmdline.c of the kernel source for the
+ original location of this code */
+kernel_mem_end = simple_strtoul(mem+4, mem);
+
+switch(*mem)
+ {
+ case 'G':
+ case 'g':
+kernel_mem_end = 10;
+ case 'M':
+ case 'm':
+kernel_mem_end = 10;
+ case 'K':
+ case 'k':
+kernel_mem_end = 10;
+ default:
+break;
+ }
+ }
+ }
+
/* Copy command-line plus memory hack to staging area.
NOTE: Linux has a bug that it doesn't handle multiple spaces
between two options and a space after a mem= option isn't
@@ -720,7 +751,9 @@
goto fail;
}
- moveto = ((mbi.mem_upper + 0x400) * 0x400 - len) 0xf000;
+ if (!kernel_mem_end)
+kernel_mem_end = (mbi.mem_upper + 0x400) * 0x400;
+ moveto = (kernel_mem_end - len) 0xf000;
if (moveto + len = LINUX_INITRD_MAX_ADDRESS)
moveto = (LINUX_INITRD_MAX_ADDRESS - len) 0xf000;
Index: stage2/char_io.c
===
RCS file: /cvsroot/grub/grub/stage2/char_io.c,v
retrieving revision 1.45
diff -u -u -r1.45 char_io.c
--- stage2/char_io.c8 Feb 2002 01:14:01 - 1.45
+++ stage2/char_io.c8 Feb 2002 20:08:33 -
@@ -967,6 +967,34 @@
return 1;
}
+/* convert a string to an unsigned long. basically taken straight from
+ * the Linux kernel (lib/vsprintf.c) but made even simpler due to lack of
+ * base handling
+ * str_ptr is the start of the string,
+ * endp will point to the end of the parsed string when we're done
+ */
+unsigned long
+simple_strtoul(char *str_ptr, char **endp)
+{
+ unsigned long result = 0;
+
+ while (1)
+ {
+ unsigned int digit;
+
+ digit = *str_ptr - '0';
+ /* since digit is unsigned, it will wrap */
+ if (digit 9)
+ break;
+ result = result * 10 + digit;
+ str_ptr++;
+ }
+
+ if (endp)
+ *endp = (char *)str_ptr;
+ return result;
+}
+
int
grub_tolower (int c)
{
Index: stage2/shared.h
===
RCS file: /cvsroot/grub/grub/stage2/shared.h,v
retrieving revision 1.84
diff -u -u -r1.84 shared.h
--- stage2/shared.h 8 Feb 2002 01:14:01 - 1.84
+++ stage2/shared.h 8 Feb 2002 20:08:33 -
@@ -918,6 +918,9 @@
int grub_strlen (const char *str);
char *grub_strcpy (char *dest, const char *src);
+/* simple version of string to unsigned long; doesn't handle bases */
+unsigned long simple_strtoul(char *str_ptr, char **endp);
+
#ifndef GRUB_UTIL
typedef unsigned long grub_jmp_buf[6];
#else
Re: problem with grub configuration
On Fri, 2002-02-08 at 13:25, Janet Anstett wrote: I have a problem with the grub configuration on my machine. I have RedHat 7.2 installed on a Dell Precision 410 machine. I am trying to set the amount of memory in the boot command. All of the stuff that I have seen says to put mem=256M at the end of the boot command. This will not work on this particular machine. I tried to do this on another machine and the machine boots fine. One difference between the two machines is the one that works has IDE drives and the one that doesn't work has SCSI drives. As Pavel replied, this is because grub doesn't take into account mem= when determining where to load the initrd. Package with the fix is sitting at http://people.redhat.com/~katzj/grub/grub-0.91-1.7x.i386.rpm. Actual patch against CVS sent a few minutes ago if you'd rather go that route (see [PATCH] Parse mem= on Linux kernel command line to change initrd load address) Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: problem with grub configuration
On Fri, 2002-02-08 at 15:21, [EMAIL PROTECTED] wrote: Pavel Roskin [EMAIL PROTECTED] wrote: GRUB loads initrd (initial reamdisk) to the end of the memory. It uses 256M of memory. But you tell the kernel that you only have 254M of memory. That's why the kernel cannot load initrd. initrd is used on RedHat to support SCSI adaptors. If it cannot be loaded, then your SCSI devices are not accessible. The best solution would be to recompile the kernel to support your SCSI adaptor in the kernel. Besides, your kernel is old - consider applying all RedHat updates. Actually, an easier solution is to, instead of adding the mem=254M to the end of the kernel command-line, tell GRUB that it has less memory to work with, and it will report that to the kernel. Do this with the uppermem command, so instead of your entry looking like the following: [snip] ...so I *think* it would instead look like this: title Red Hat Linux (2.4.7-10smp) uppermem 259072 root (hd0,0) kernel /boot/vmlinuz-2.4.7-10smp ro root=/dev/sda1 initrd /boot/initrd-2.4.7-10smp.img You also still need to pass mem= on the kernel command line if you go this route. Having grub pass its detected memory to the kernel by default with a 2.4 kernel leads to problems due to not taking into account any holes which you may have in your memory layout, thus is disabled in the Red Hat Linux packages. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: problem with grub configuration
On Fri, 2002-02-08 at 15:50, [EMAIL PROTECTED] wrote: Jeremy Katz [EMAIL PROTECTED] wrote: Do this with the uppermem command, so instead of your entry looking like the following: [snip] ...so I *think* it would instead look like this: title Red Hat Linux (2.4.7-10smp) uppermem 259072 root (hd0,0) kernel /boot/vmlinuz-2.4.7-10smp ro root=/dev/sda1 initrd /boot/initrd-2.4.7-10smp.img You also still need to pass mem= on the kernel command line if you go this route. Having grub pass its detected memory to the kernel by default with a 2.4 kernel leads to problems due to not taking into account any holes which you may have in your memory layout, thus is disabled in the Red Hat Linux packages. What? OK, I'm confused. Do you mean, removed from the Red Hat Linux *GRUB* package? We run configure with --disable-auto-linux-mem-opt (as do most distros shipping 2.4 kernels from my looking through others' packages). I looked at the Red Hat kernel source, and it seemed clear that the kernel already handles this just fine. It parses the mem= option as just one memory region. I even tested this out on one of my huge memory boards recently (from recent GRUB CVS), and it worked perfectly fine, restricting one memory region while allowing for the others. GRUB's mem= option it passes takes into account memory holes just fine, but not putting anything above the first hole into there, which is what the kernel source expects. Maybe I'm missing something here? From what I understand from talking with our kernel folks, using mem= without passing along the complete e820 memory map info is not guaranteed to give proper memory information in all cases. Thus, passing mem= by default without an e820 map can cause problems. But, IANAKH (I am not a kernel hacker :) and instead just listen to what those who in theory know more about these things give me information :-) Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Bug-grub] splashimage support
On Tue, 2002-01-29 at 17:21, Jason Thomas wrote: On Tue, Jan 29, 2002 at 01:20:31PM -0600, inittab wrote: how can i add splashimage support to grub, i find nothing about it in the documentation but i see all these people using it, is this a patch to the grub source or what? ive tried the main source off of gnu.org and also the debian packages, any help appreciated I think the redhat package has the patch in it. or you can try searching the grub mail archives if they exist. debian does not as I'm trying to stay as close to upstream as possible. You can either get the diff from Conectiva's CVS repository or I just scp'd all of the patches from the most recent build to http://people.redhat.com/~katzj/grub/patches/. Some of these patches aren't used anymore since they're integrated as of 0.91 or earlier and I just haven't gotten around to removing them from the source RPM. The splashimage patch is the grub-0.91-vga16.patch. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Can't configure grub to use less memory
On Wed, 2002-01-23 at 17:19, Darren Gamble wrote: Lastly, we also tried to manually add mem=800M onto the end of the kernel boot line. The GNU grub faq suggests to do this, and kickstart also does this if it's specified in its configuration. If that's done, when the machine boots the root filesystem doesn't get found and the system halts. Bootup reports: The problem is that GRUB doesn't properly follow the Linux/i386 boot protocol. Someone filed something similar in bugzilla a few months ago, but I just got around to really looking at it and pinning down the problem last night. Basically, the problem is that grub needs to parse the mem= and change where it loads the initrd accordingly instead of just loading it at the top of its detected memory area. I started working on it then, but got distracted by sleep :) Hopefully I'll get around to finishing it in the next few days-ish. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: ramdisk_size
On Fri, 2002-01-11 at 11:37, Ísak Ben. wrote: i need to use a fairly large ramdisk on my server but grub wont adjust it properly, my config looks like this title Red Hat Linux (2.4.9-13) root (hd0,4) kernel /boot/vmlinuz-2.4.9-13 ro root=/dev/md0 initrd /boot/initrd-2.4.9-13.img ramdisk_size=12 Use something like the following instead: title Red Hat Linux (2.4.9-13) root (hd0,4) kernel /boot/vmlinuz-2.4.9-13 ro root=/dev/md0 ramdisk_size=12000 initrd /boot/initrd-2.4.9-13.img Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] Support mktemp as well as tempfile for creation oftempfiles in grub-install
This patch lets grub-install check for both /bin/tempfile and
/bin/mktemp for tempfile creation as Red Hat Linux ships BSD mktemp
instead of tempfile.
Cheers,
Jeremy
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.452
diff -u -u -r1.452 ChangeLog
--- ChangeLog 30 Dec 2001 08:23:16 - 1.452
+++ ChangeLog 2 Jan 2002 17:54:42 -
@@ -1,3 +1,8 @@
+2002-01-02 Jeremy Katz [EMAIL PROTECTED]
+
+ * util/grub-install.in: Support using mktemp as well as tempfile
+ for secure temporary file creation
+
2001-12-30 Yoshinori K. Okuji [EMAIL PROTECTED]
* stage1/stage1.S: Don't call INT 13, AH=48H, because it is
Index: util/grub-install.in
===
RCS file: /cvsroot/grub/grub/util/grub-install.in,v
retrieving revision 1.32
diff -u -u -r1.32 grub-install.in
--- util/grub-install.in29 Dec 2001 18:53:30 - 1.32
+++ util/grub-install.in2 Jan 2002 17:54:42 -
@@ -39,6 +39,16 @@
recheck=no
debug=no
+# look for secure tempfile creation wrappers on this platform
+if test -x /bin/tempfile; then
+mkstemp=/bin/tempfile --prefix=grub
+elif test -x /bin/mktemp; then
+mkstemp=/bin/mktemp /tmp/grub-install.log.XX
+else
+mkstemp=
+fi
+
+
# Usage: usage
# Print the usage.
usage () {
@@ -268,7 +278,7 @@
:
else
# Create a safe temporary file.
-test -x /bin/tempfile log_file=`tempfile --prefix=grub`
+test -n $mkstemp log_file=`$mkstemp`
$grub_shell --batch --device-map=$device_map EOF $log_file
quit
@@ -342,7 +352,7 @@
done
# Create a safe temporary file.
-test -x /bin/tempfile log_file=`tempfile --prefix=grub`
+test -n $mkstemp log_file=`$mkstemp`
# Now perform the installation.
$grub_shell --batch --device-map=$device_map EOF $log_file
Re: GRUB and framebuffer
On Mon, 2001-12-10 at 18:55, Oliver Roeschke wrote: Does GRUB have an option similiar to the vga and append so that I gave give the options I need to get my framebuffer Xserver to work??? Just add the necessary options to the end of your kernel line in your GRUB config file, eg title foo root (hd0,0) kernel /vmlinuz ro root=/dev/hda2 vga=791 Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Gnu Grub Manual
On Sat, 2001-11-17 at 23:54, William (Andy) Smith wrote: On Fri, 16 Nov 2001, Jochen Hoenicke wrote: Okuji, do you think this link should be added to the project page and/or the FAQ? I had a question about rewriting the MBR after swapping out raid. The Gnu Grub Manual had just the answer I needed, so I'm all set. More than just the link to the Gnu Grub Manual on the site, I sure wish RedHat would put this manual in /usr/share/docs with the rest of the Grub info. :) This information *is* available in the packages, just in info format as it's shipped to build by default from the tarball. Use your favorite info view (pinfo, emacs, info) to view it. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: serial problems with grub-0.90
On Mon, 2001-11-12 at 13:44, Pragnesh Sampat wrote: This machine does not have a console. It has one serial port ttyS0/COM1 which is connected to another x86 linux box with a serial cable. I was passing console=XXX options to lilo which I did with GRUB and I am at least where I was with the lilo config. I can see the boot messages starting with the Linux version 2.4.7 ... etc. and get a login shell on the. serial line, just like lilo. So far, so good. Can I get the grub menu and boot options in my serial terminal? I tried: GRUB version 0.90 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub serial --unit=0 --speed=9600 Error 30: Invalid argument From the grub shell, you need to use something like grub serial --unit=/dev/ttyS0 --speed=9600 grub terminal serial Segmentation fault (core dumped) This segfault has been fixed in CVS. Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Bug-grub: Promise Ultra33 issues
On Tuesday, October 30 2001, pa said: System currently; PII in an Asus Promise Ultra33 Disk 1 at hda CD at hdc Disk 2 at hde Disk 3 at hdg The last 2 drives hanging off of the Promise Ultra33. No go with Grub at that point, instead of the Grub menu at boot time just a blinking underscore. If I enter the proper commands with a Grub boot floppy, I can boot any of the systems. What does your /boot/grub/device.map look like? Cheers, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: GRUB loops, printing GRUB
On Tuesday, September 04 2001, Geoffrey Leach said: There are 3 SCSI HDs and no IDE on this system. Motherboard is Intel Venus with a PPro. The SCSI controller is and Adaptec 29160N The BIOS is set to boot from ID 1, which has a freshly-installed RedHat Roswell (7.1.94). SCSI ID 0 has a LILO boot. Some Adaptec controllers seem to have problems with the int13 extensions (lba32) used with GRUB. Could you try disabling them in the SCSI BIOS to see if that helps? Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] Ensure serial device exists prior to use
We shouldn't try to use the serial terminal if the user hasn't properly
configured it yet. This patch (against current CVS) makes it so ensures
that we have set up a serial port prior to switching to a serial
terminal.
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.428
diff -u -r1.428 ChangeLog
--- ChangeLog 2001/08/08 05:17:20 1.428
+++ ChangeLog 2001/08/08 05:46:58
@@ -1,3 +1,13 @@
+2001-08-08 Jeremy Katz [EMAIL PROTECTED]
+
+ * grub/asmstub.c, stage2/serial.c, stage2/serial.h:
+ add serial_exists() function to ensure that serial port is set up
+ prior to use
+
+ * stage2/builtins.c:
+ use serial_exists when serial terminal is selected or fallback to
+ previous terminal definition
+
2001-08-08 OKUJI Yoshinori [EMAIL PROTECTED]
* util/grub-md5-crypt.in: Prefix backquotes with backslashes in
Index: grub/asmstub.c
===
RCS file: /cvsroot/grub/grub/grub/asmstub.c,v
retrieving revision 1.70
diff -u -r1.70 asmstub.c
--- grub/asmstub.c 2001/05/03 08:34:56 1.70
+++ grub/asmstub.c 2001/08/08 05:46:59
@@ -1026,6 +1026,21 @@
return 0;
}
+/* Do we have a serial port set up? In the grub shell, we should check
+ if the fd is open */
+int serial_exists(void)
+{
+ grub_printf(serial_fd is %d\n, serial_fd);
+ if (serial_fd = 0)
+{
+ return 1;
+}
+ else
+{
+ return 0;
+}
+}
+
/* Initialize a serial device. In the grub shell, PORT is unused. */
int
serial_init (unsigned short port, unsigned int speed,
Index: stage2/builtins.c
===
RCS file: /cvsroot/grub/grub/stage2/builtins.c,v
retrieving revision 1.112
diff -u -r1.112 builtins.c
--- stage2/builtins.c 2001/06/21 23:15:02 1.112
+++ stage2/builtins.c 2001/08/08 05:47:02
@@ -3914,9 +3914,18 @@
#ifdef SUPPORT_SERIAL
else if (grub_memcmp (arg, serial, sizeof (serial) - 1) == 0)
{
- terminal |= TERMINAL_SERIAL;
- if (! default_terminal)
- default_terminal = TERMINAL_SERIAL;
+ if (serial_exists())
+ {
+ terminal |= TERMINAL_SERIAL;
+ if (! default_terminal)
+ default_terminal = TERMINAL_SERIAL;
+ }
+ else
+ {
+ terminal = saved_terminal;
+ grub_printf(No serial device configured.\n);
+ grub_printf(Resetting to previous terminal configuration.\n);
+ }
}
#endif /* SUPPORT_SERIAL */
else
Index: stage2/serial.c
===
RCS file: /cvsroot/grub/grub/stage2/serial.c,v
retrieving revision 1.3
diff -u -r1.3 serial.c
--- stage2/serial.c 2000/08/26 17:36:07 1.3
+++ stage2/serial.c 2001/08/08 05:47:02
@@ -31,7 +31,7 @@
};
/* Store the port number of a serial unit. */
-static unsigned short serial_port;
+static unsigned short serial_port = -1;
/* The table which lists common configurations. */
static struct divisor divisor_tab[] =
@@ -100,6 +100,15 @@
return;
outb (serial_port + UART_TX, c);
+}
+
+/* do we have a serial port set up? */
+int
+serial_exists (void)
+{
+ if (serial_port == -1)
+return 0;
+ return 1;
}
/* Return the port number for the UNITth serial device. */
Index: stage2/serial.h
===
RCS file: /cvsroot/grub/grub/stage2/serial.h,v
retrieving revision 1.5
diff -u -r1.5 serial.h
--- stage2/serial.h 2000/08/26 17:36:07 1.5
+++ stage2/serial.h 2001/08/08 05:47:02
@@ -93,6 +93,9 @@
int serial_init (unsigned short port, unsigned int speed,
int word_len, int parity, int stop_bit_len);
+/* Do we have a serial port set up? */
+int serial_exists (void);
+
#ifdef GRUB_UTIL
/* Set the file name of a serial device (or a pty device). This is a
function specific to the grub shell. */
___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] Copy stages prior to device probes in grub-install
Currently, grub-install probes for devices before it copies stageX to
grubdir which causes grub-install to always fail on the first run being
unable to find any drives.
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.428
diff -u -r1.428 ChangeLog
--- ChangeLog 2001/08/08 05:17:20 1.428
+++ ChangeLog 2001/08/08 05:50:31
@@ -1,3 +1,8 @@
+2001-08-08 Jeremy Katz [EMAIL PROTECTED]
+
+ * util/grub-install.in:
+ copy GRUB stages into the grubdir prior to probing for devices
+
2001-08-08 OKUJI Yoshinori [EMAIL PROTECTED]
* util/grub-md5-crypt.in: Prefix backquotes with backslashes in
Index: util/grub-install.in
===
RCS file: /cvsroot/grub/grub/util/grub-install.in,v
retrieving revision 1.28
diff -u -r1.28 grub-install.in
--- util/grub-install.in2001/07/13 11:51:24 1.28
+++ util/grub-install.in2001/08/08 05:50:31
@@ -225,6 +225,15 @@
test -d $bootdir || mkdir $bootdir || exit 1
test -d $grubdir || mkdir $grubdir || exit 1
+# Copy the GRUB images to the GRUB directory.
+for file in ${grubdir}/stage1 ${grubdir}/stage2 ${grubdir}/*stage1_5; do
+rm -f $file || exit 1
+done
+for file in \
+${pkgdatadir}/stage1 ${pkgdatadir}/stage2 ${pkgdatadir}/*stage1_5; do
+cp -f $file ${grubdir} || exit 1
+done
+
# If --recheck is specified, remove the device map, if present.
if test $recheck = yes; then
rm -f $device_map
@@ -298,15 +307,6 @@
EOF
exit 1
fi
-
-# Copy the GRUB images to the GRUB directory.
-for file in ${grubdir}/stage1 ${grubdir}/stage2 ${grubdir}/*stage1_5; do
-rm -f $file || exit 1
-done
-for file in \
-${pkgdatadir}/stage1 ${pkgdatadir}/stage2 ${pkgdatadir}/*stage1_5; do
-cp -f $file ${grubdir} || exit 1
-done
# Create a safe temporary file.
test -x /bin/tempfile log_file=`tempfile --prefix=grub`
___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
[PATCH] grub-install --just-copy
grub-install unfortunately relies upon df for doing its drive mappings
which is a bit unreliable if you're in an environment without an mtab.
This patch makes it so that grub-install can be used at least to just
install the stages into the grubdir
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub/ChangeLog,v
retrieving revision 1.428
diff -u -r1.428 ChangeLog
--- ChangeLog 2001/08/08 05:17:20 1.428
+++ ChangeLog 2001/08/08 05:56:00
@@ -1,3 +1,8 @@
+2001-08-08 Jeremy Katz [EMAIL PROTECTED]
+
+ * util/grub-install.in:
+ add --just-copy for just copying images to grubdir
+
2001-08-08 OKUJI Yoshinori [EMAIL PROTECTED]
* util/grub-md5-crypt.in: Prefix backquotes with backslashes in
Index: util/grub-install.in
===
RCS file: /cvsroot/grub/grub/util/grub-install.in,v
retrieving revision 1.28
diff -u -r1.28 grub-install.in
--- util/grub-install.in2001/07/13 11:51:24 1.28
+++ util/grub-install.in2001/08/08 05:56:01
@@ -38,6 +38,7 @@
force_lba=
recheck=no
debug=no
+justcopy=no
# Usage: usage
# Print the usage.
@@ -150,6 +151,17 @@
fi
}
+copy_images() {
+# Copy the GRUB images to the GRUB directory.
+for file in ${grubdir}/stage1 ${grubdir}/stage2 ${grubdir}/*stage1_5; do
+ rm -f $file || exit 1
+done
+for file in \
+ ${pkgdatadir}/stage1 ${pkgdatadir}/stage2 ${pkgdatadir}/*stage1_5; do
+ cp -f $file ${grubdir} || exit 1
+done
+}
+
# Check the arguments.
for option in $@; do
case $option in
@@ -167,6 +179,8 @@
force_lba=--force-lba ;;
--recheck)
recheck=yes ;;
+--just-copy)
+justcopy=yes ;;
# This is an undocumented feature...
--debug)
debug=yes ;;
@@ -180,12 +194,6 @@
esac
done
-if test x$install_device = x; then
-echo install_device not specified. 12
-usage
-exit 1
-fi
-
# If the debugging feature is enabled, print commands.
if test $debug = yes; then
set -x
@@ -196,6 +204,18 @@
grubdir=${bootdir}/grub
device_map=${grubdir}/device.map
+# if they just want the images copied, copy the images and then exit
+if test $justcopy = yes; then
+copy_images
+exit 0
+fi
+
+if test x$install_device = x; then
+echo install_device not specified. 12
+usage
+exit 1
+fi
+
# Check if GRUB is installed
if test -f $grub_shell; then
:
@@ -299,14 +319,7 @@
exit 1
fi
-# Copy the GRUB images to the GRUB directory.
-for file in ${grubdir}/stage1 ${grubdir}/stage2 ${grubdir}/*stage1_5; do
-rm -f $file || exit 1
-done
-for file in \
-${pkgdatadir}/stage1 ${pkgdatadir}/stage2 ${pkgdatadir}/*stage1_5; do
-cp -f $file ${grubdir} || exit 1
-done
+copy_images
# Create a safe temporary file.
test -x /bin/tempfile log_file=`tempfile --prefix=grub`
___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
Determining if GRUB is the bootloader in use on a system
As may or may not have been noticed, we are giving GRUB as the primary boot loader in the Red Hat Linux public beta released the end of last week. Unfortunately, due to the vagueries of hardware just being weird and lack of the kind of widespread use that LILO has seen, LILO is still offered as an option during the installation process. The difficult problem is being able to tell post-install whether GRUB or LILO is the bootloader being used as GRUB does not overwrite the area of the BPB where LILO writes its magic identifier. Am I just being blind and missing the easy way to check and tell if GRUB is being used as the boot loader? If not, what would people think of checking during first stage installation to see if the LILO magic is present, and if so, overwrite it (using GRUB seems sort of fitting, but just zero'ing it out has merits as well)? Thanks, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: grub command works, but GRUB boot loader hangs
On Sunday, August 05 2001, Ben Liblit said: Recall that this system has a SCSI controller with two drives, one of which is ordinarily used as the boot drive. There's also an old IDE drive hanging off the secondary channel, a SCSI CD-ROM, and a floppy tape drive controller. (For more complete details, see http://mail.gnu.org/pipermail/bug-grub/2001-August/005353.html for my original message, or http://mail.gnu.org/pipermail/bug-grub/2001-August/005360.html for a shorter configuration summary produced by fdisk -l.) So, to clarify, in your BIOS, you have boot order set to something like A/SCSI/C or something similar to that (depending of course on BIOS manufacturer and how they decided they wanted to denote things). Also, what does /boot/grub/device.map look like? First off, the floppy tape drive controller is not relevant. I can remove the card and nothing changes. I thought that perhaps this controller was causing the extra (fd1) floppy drive to be detected, but apparently that's not where it's coming from. Since you are running Roswell and therefore have a recent kudzu, can you get the output of `/usr/sbin/kudzu -p -c FLOPPY`? Unplugging the secondary master IDE hard drive has no effect. This is surprising, because when GRUB is working correctly it should detect this drive and make it available. Actually, depending on your BIOS boot order and the contents of the device.map, this drive may not actually be accessible. Thanks, Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
RFC: Change Name of Default Config File
Hi, I've been looking some at grub recently and one thing that really doesn't make sense from the point of view of just being a user is the name of the default config file being menu.lst. I would like to propose that this should instead be grub.conf as that seems to be something that users can more easily figure out and remember as well as being more in-line with how other bootloaders name their config files. Any comments on reasons why or why this wouldn't be a good idea? If people agree, I can put together a patch against the current grub CVS to update the docs and such to change the default. Jeremy ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
