Syslinux - Jun 2010 - [PATCH] chain.c32: add support for loading GRUB stage2

This adds (basic) support for GRUB stage2 image files.

Loading a stage2 image will probably give you a GRUB prompt, with GRUB's
"root" set at "(hd0)" (ie, entire first disk). Maybe the
"root" will
differ in less common setups. (One can of course select another disk
and/or partition with GRUB's "root" command.)

This has only been tested with version 3.2 stage2 images (as used by
GRUB 0.97). I'm not familiair with differences with other versions.

GRUB's loading mechanism allows to somehow provide stage2 with the
selected disk and partition, BSD slice, etc. (ie, to tell stage2 what
it's "root" is). I don't yet understand the notation used in
that
mechanism. Besides, since stage2 images will not necessarily be loaded
from the disk (and partition, etc.) they were installed to, it seems
best to just use the first disk.

GRUB stage1_5 image files load quite similarly. However, for some
reason, a short test only got those images to print an error ("Error
17"). This could be related to the partition info these images are
provided with when they're loaded. I have never used stage1_5 images,
and do not know how to properly use and configure those, so my test
stopped there, and stage1_5 images are not supported.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
 com32/modules/chain.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/com32/modules/chain.c b/com32/modules/chain.c
index ad746ee..93bba4e 100644
--- a/com32/modules/chain.c
+++ b/com32/modules/chain.c
@@ -63,6 +63,10 @@
  *	equivalent to seg=0x70 file=<loader> sethidden,
  *      used with DOS' io.sys.
  *
+ * grub=<loader>:
+ *	same as seg=0x800 file=<loader> & jumping to seg 0x820,
+ *      used with GRUB stage2 files.
+ *
  * swap:
  *	if the disk is not fd0/hd0, install a BIOS stub which swaps
  *	the drive numbers.
@@ -101,6 +105,7 @@ static struct options {
     bool swap;
     bool hide;
     bool sethidden;
+    bool grub;
 } opt;
 
 struct data_area {
@@ -679,6 +684,7 @@ static void usage(void)
 	  "         freedos=<loader>   load FreeDOS kernel.sys\n"
 	  "         msdos=<loader>     load MS-DOS io.sys\n"
 	  "         pcdos=<loader>     load PC-DOS ibmbio.com\n"
+	  "         grub=<loader>      load GRUB stage2\n"
 	  "         seg=<segment>      jump to <seg>:0000 instead of
0000:7C00\n"
 	  "         swap               swap drive numbers, if bootdisk is not
fd0/hd0\n"
 	  "         hide               hide primary partitions, except selected
partition\n"
@@ -742,6 +748,10 @@ int main(int argc, char *argv[])
 	    opt.seg = 0x70;	/* MS-DOS 2.0+ wants this address */
 	    opt.loadfile = argv[i] + 6;
 	    opt.sethidden = true;
+	} else if (!strncmp(argv[i], "grub=", 5)) {
+	    opt.seg = 0x800;	/* stage2 wants this address */
+	    opt.loadfile = argv[i] + 5;
+	    opt.grub = true;
 	} else if (!strcmp(argv[i], "swap")) {
 	    opt.swap = true;
 	} else if (!strcmp(argv[i], "noswap")) {
@@ -945,6 +955,15 @@ int main(int argc, char *argv[])
 	    }
 	}
 
+	if (opt.grub) {
+		regs.ip = 0x200; /* jump 0x200 bytes into the loadfile */
+
+		/* 0xffffff00 seems to be GRUB ways to record that it's
+		   "root" is the whole disk (and not a partition). */
+		*(uint32_t *) ((unsigned char *) data[ndata].data + 0x208) +			0xffffff00ul;
+	}
+
 	ndata++;
     }
 
-- 
1.7.1

> This has only been tested with version 3.2 stage2 images (as used by
> GRUB 0.97). I'm not familiair with differences with other versions.
This seems to work well for grub 0.97. I was able to get to a grub
prompt and chainload my extlinux installation from there :)

Note that grub 2 is apparently a multiboot image and thus one should be
able to load grub2's core.img with mboot.c32 - I didn't succeed so far.
> GRUB's loading mechanism allows to somehow provide stage2 with the
> selected disk and partition, BSD slice, etc. (ie, to tell stage2 what
> it's "root" is). I don't yet understand the notation used
in that
> mechanism. Besides, since stage2 images will not necessarily be loaded
> from the disk (and partition, etc.) they were installed to, it seems
> best to just use the first disk.
I believe that is not the purpose of stage2's "root". When stage2
is
loaded, it looks for a file /grub/menu.lst or /boot/grub/menu.lst to
read a configuration from. My guess is that the "root" in this case is
the device where it looks for that file.

Without menu.lst, grub will just show a prompt. If I am right, it would
be very useful to be able to APPEND a "root" so that a chainloaded
grub
can load a configuration file without user intervention.
> GRUB stage1_5 image files load quite similarly. However, for some
> reason, a short test only got those images to print an error ("Error
> 17"). This could be related to the partition info these images are
> provided with when they're loaded. I have never used stage1_5 images,
> and do not know how to properly use and configure those, so my test
> stopped there, and stage1_5 images are not supported.
It doesn't make much sense to chainload stage1_5 images: Their only
purpose is to read the file system where stage2 is stored and chainload
stage2 (In grub 2, stage 1.5 has been eliminated entirely). As we can
load stage2 directly, there is no need for stage1_5 to do that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20100608/ffdc7327/attachment.sig>