[syslinux] [PATCH] chain.c32: add support for loading GRUB stage2

[Thomas Bächler]

> 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>