19 replies to this topic

[Icecube]

Grub4dos can't chainload my second logical partition (EXTLINUX installed) correctly:
[codebox]$ 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... */[/codebox] 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...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 Files

•  grldr.zip   114.48KB   389 downloads

[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...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):

title Boot Extlinux

root (hd0,5)

chainloader (hd0,5)+1

I get (EXTLINUX error):

Boot Error

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

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

[Icecube]

I did some more tests.
The problem ("Boot Error") only seems to exist with EXTLINUX installed on the partition (only tried on logical partitions). I can chainload SYSLINUX from a logical partition just fine.

[tinybit]

@Icecube

See this line in the function set_bootdev():

if (kernel_type != KERNEL_TYPE_FREEBSD && kernel_type != KERNEL_TYPE_NETBSD)

		return 0;

That means, if it is not of a BSD booting, the remaining code will not execute.

You should find an earlier version without the above BSD check code.

I should add that there is a rawread() call in the remaining code. This call has caused conflict with other portion of the grub4dos code. The truth(the actual fact) was very hidden and very difficult to find out.

[Icecube]

When removing:

if (kernel_type != KERNEL_TYPE_FREEBSD && kernel_type != KERNEL_TYPE_NETBSD)

		return 0;

I can boot EXTLINUX now from my logical partitions.

So a proper way of doing this would be appreciated.

MS use the BPB "hidden sectors" on boot. It never need SI. If we do not want to add complexity to the boot logic, we should not continue to use the SI.

All of this goes straight to hell with > 2 TB disks, too. That's why I'm trying to push an in-memory protocol through T13. We can't set "hidden sectors" on-disk for > 2 TB without overwriting random data, while it is possible with an extension of the DS:SI protocol.

[tinybit]

All of this goes straight to hell with > 2 TB disks, too. That's why I'm trying to push an in-memory protocol through T13. We can't set "hidden sectors" on-disk for > 2 TB without overwriting random data, while it is possible with an extension of the DS:SI protocol.

When placed on sectors > 2T, DOS(and all those old things) will not work. So solving this problem is not meaningful for them. For newer systems, they will establish their new protocol. So we never need to create new protocol of our own. We can simply use protocols by others.

[Icecube]

I did forget a quote:

Hidden sectors" is FAT-specific; walking the partition table from scratch is partition-table-format specific

[tinybit]

NTFS also uses "hidden sectors".

MS is "de facto" standard of the PC industry. Even some BIOS makers follow MS standard. There are reports saying that some USB BIOSes can only boot up a boot sector with FAT and NTFS filesystems, while a boot sector with other filesystems, e.g., ext2, will not boot. The MBR could simply be skipped in that case.

For sure, the OS makers will create their protocol, no matter who they are. I would like to wait for their standard and simply use it.

At this moment, I would not like to take into careful consideration of the 2T issue.

I should add some words. I am now no longer a maintainer of grub4dos. And I am not opposed to the proposal of re-enabling the DS:SI pointer. Patches can be made, and maintainers are likely to accept.

[Icecube]

When Grub4Dos corrects the hidden sector data, are those changes only in memory or also written to disk?

[tinybit]

Only when the boot sector is to be chainloaded could the BPB be corrected. And only the memory image of the boot sector at 0000:7C00 will change. It does not write to disk. But in some cases, the partnew command will write to disk and correct the "hidden sectors" in the BPB.

The "hidden sectors" is only used by the boot sector code. It has never been used by the OS.

If "hidden sectors" has a wrong value, the boot will fail. But if the BPB at 0000:7C00 is corrected, the boot will succeed.

[Icecube]

chain.c32 of syslinux-3.85-pre11 now loads the boot sector of the partition and corrects the hidden sectors when booting NTLDR, BOOTMGR, io.sys and kernel.sys.

Testers are welcome.

[Icecube]

More info about the original problem:

Gavin D. Smith wrote:
> H. Peter Anvin wrote:
>
>> Gavin D. Smith wrote:
>>> I have just tried placing EXTLINUX on a primary partition and indeed
>>> I successfully chainloaded it. However this doesn't seem to work when
>>> I put it on a logical partition. Is there a reason why there might be
>>> a difference between the two types?
>>
>> Not if the chainloading code is written properly. Chainloading onto a
>> logical partition means you have to load not the MBR but the
>> pseudo-MBR containing the logical partition in question at address
>> 0x600 and point DS:SI to it.
>>
>> Sounds like a Grub problem to me.
>>
>> -hpa
>>
> To see if Grub has a problem chainloading onto a logical partition I
> tried installing GRUB onto the logical partition, and it was
> successfully loaded. I also tried LILO on the logical partition, and it
> also was successfully loaded. However trying extlinux I got the same
> "Boot error" message as before. This may be because of a slight
> difference in my installing methods that I have overlooked, but I don't
> know what that might be. I know that the syslinux loader is loaded
> because "Boot error" is a message in that loader. So you say this
> message is due to some registers not being set correctly? Would there be
> a way of seeing what the registers contain so I can tell if they're
> right or not? I don't have many more ideas of things to try.
>

You're assuming that just because GRUB and LILO can be loaded that it is
all done correctly. GRUB and LILO might not rely on, for example, the
DS:SI pointer (given their design methodology I would almost assume they
don't.)

For debugging, I would run this in an simulator and set a breakpoint at
0:7C00h. This will be hit several times, one of which will be EXTLINUX
entry; at this point examine the registers, and the memory pointed to by
DS:SI (16 bytes) and ES:DI (64 bytes or so.)

-hpa

The registers are supposed to have the following values:

DL is supposed to have the drive number.
DS:SI is supposed to point to the 16-byte partition entry, which
typically should be located in memory between address 0x600 and 0x800.
ES:DI is supposed to point to the $PnP header.

-hpa

http://syslinux.zyto...ber/007527.html and replies.