Chainloading bootsector of logical partition with EXTLINUX installed, fails. Patch included, Logical-partition-residing bootloader chainload patch External links Options

[Icecube]

Grub4dos can't chainload my second logical partition (EXTLINUX installed) correctly:

CODE

title Boot Extlinux
root (hd0,5)
chainloader (hd0,5)+1

EXTLINUX (and SYSLINUX) trust the info from the loader that loads the boot sector of the partition, not the partition offset stored on the partition itself.

A patch for Grub Legacy can be found:
Logical-partition-residing bootloader chainload patch for GRUB Legacy
http://bugs.gentoo.org/230905
http://forums.gentoo.org/viewtopic.php?p=5142693#5142693

It needs a little adaptation before you can apply it:

CODE

$ diff -u stage2/disk_io.c.orig stage2/disk_io.c
--- stage2/disk_io.c.orig 2009-06-20 17:53:46.000000000 +0200
+++ stage2/disk_io.c 2010-01-27 21:31:59.939631640 +0100
@@ -49,6 +49,9 @@
static char *unique_string;
static unsigned long cur_part_offset;
static unsigned long cur_part_addr;
+static unsigned long cur_part_start;
+static int cur_part_entry;
+
static int do_completion;

int dir (char *dirname);
@@ -525,6 +528,7 @@
src = (char *) SCRATCHADDR + BOOTSEC_PART_OFFSET;
while (dst < (char *) BOOT_PART_TABLE + BOOTSEC_PART_LENGTH)
*dst++ = *src++;
+ PC_SLICE_START (BOOT_PART_TABLE - PC_SLICE_OFFSET, cur_part_entry) = cur_part_start;

/* Clear the active flag of all partitions. */
for (i = 0; i < 4; i++)
@@ -965,6 +969,8 @@

cur_part_offset = part_offset;
cur_part_addr = BOOT_PART_TABLE + (entry << 4);
+ cur_part_start = part_start;
+ cur_part_entry = entry;
#endif /* ! STAGE1_5 */

/* If this is a valid partition... */

I can't compile Grub4dos (configure: error: GRUB requires a working absolute objcopy; upgrade your binutils), so if anyone can compile it, I can test it (patch against the 2009-06-20 version, not the experimental versions).

[Wonko the Sane]

Cross linking to this thread (though cannot say if an actual connection exists):
http://www.boot-land.net/forums/index.php?showtopic=10200

Wonko

[Sha0]

Attached is your patched GRLDR.

EDIT: Upload failed. You are not permitted to upload this type of file

Ok, then. Never mind.

EDIT: Needed to put it in a .ZIP file, I guess.

Attached File(s)

 grldr.zip ( 114.48K ) Number of downloads: 81

 

[Wonko the Sane]

Attached is your patched GRLDR.

You should stop using these Romulan cloaking devices for attachments....



Wonko

[Sha0]

You should stop using these Romulan cloaking devices for attachments....

Fixed now.

[Wonko the Sane]

Fixed now.

Yep, the United Federation of Planet technology is a bit dated, and likes only .zip or .7z archives.....

Hopefully soon some Cardassian technology will inject some new features....

Wonko

[Icecube]

It doesn't work with the patched grldr

[davlak]

WOW as predicted by WONKO this patch solved my problem too

http://www.boot-land.net/forums/index.php?showtopic=10200

many many thanks!

[Wonko the Sane]

Hmmm.


If I get it right it now works on davlak's problem that is slightly different from the one Icecube tried to fix?

Icecube had a problem in chainloading the PBR of a Logical Volume inside extended.
davlak had a problem in accessing the Logical Volume inside extended.

I guess a further patch to the patch is needed.

Wonko

[Icecube]

When I do (original and patched version):

CODE

title Boot Extlinux
root (hd0,5)
chainloader (hd0,5)+1

I get (EXTLINUX error):

CODE

Boot Error

I can list all files and folders correctly (original and patched version):

CODE

root (hd0,5)
ls /

EXTLINUX and SYSLINUX need the correct value in SI:

If an active partition is found, that partition's boot record is read into 0000:7c00 and the MBR code jumps to 0000:7c00 with SI pointing to the partition table entry that describes the partition being booted. The boot record program uses this data to determine the drive being booted from and the location of the partition on the disk.

http://www.ata-atapi.com/hiwmbr.html