14-Jul-00 05:00 you wrote:
> From: "Khimenko Victor" <[EMAIL PROTECTED]>
> Subject: Re: Linux 2.4.0-Test{1,2} with Grub (I think I found the answer)
> Date: Thu, 13 Jul 2000 20:46:30 +0400 (MSD)
>> I do not think it justifies GRUB unability to load such kernel: latest LiLo
>> works fine for it...
> Then, send a patch. It is easy to just complain.
Huh. Patch is trivial. Really trivial. Just one problem: I do not think it'll
be applied. Since it's TWO patches: one for kernel and one for GRUB.
For kernel you need this trivial patch:
-- cut --
--- arch/i386/boot/build.c.orig Thu Jul 13 17:20:36 2000
+++ arch/i386/boot/build.c Thu Jul 13 17:22:20 2000
@@ -180,9 +180,7 @@
die("Write of setup sector count failed");
if (lseek(1, 500, SEEK_SET) != 500)
die("Output: seek failed");
- buf[0] = (sys_size & 0xff);
- buf[1] = ((sys_size >> 8) & 0xff);
- if (write(1, buf, 2) != 2)
+ if (write(1 &sys_size, 4) != 4)
die("Write of image length failed");
return 0; /* Everything is OK */
-- cut --
Who's the bright idea was to extend maximum kernel beyond 1MB and STILL write
only two bytes of sys_size in boot sector anyway ? And why it was done via
buf in first place ?
But even then GRUB will not use full size of this field so you need equially
trivial patch for GRUB:
-- cut --
--- grub-0.5.94.orig/stage2/boot.c Thu Dec 30 09:32:02 1999
+++ grub-0.5.94/stage2/boot.c Fri Jul 14 04:11:34 2000
@@ -195,7 +195,7 @@
(buffer + LINUX_SETUP_LEN_OFFSET))) << 9))
<= LINUX_SETUP_MAXLEN)
&& ((text_len
- = (((long) *((unsigned short *)
+ = (((long) *((unsigned int *)
(buffer + LINUX_KERNEL_LEN_OFFSET))) << 4)),
(data_len + text_len + SECTOR_SIZE) <= ((filemax + 15) & 0xFFFFFFF0)))
{
-- cut --
It's safe to do: even if build.c writing two bytes there in this place in
first sector int variable is places so it'll be four bytes long zero initially.
