I've been testing different builds and updating every so often and it'd seem as though after updating to r135 GRUB can no longer identify any of my partitions. If I switch back to r134 then I can boot perfectly fine.

I can only guess the GPT changes are interfering but I'm not sure what else I can provide to help. I can tell you that using the geometry command the output is just "drive 0x80(LBA): C/H/S=1024/255/63, Sector Count/Size=1953521664/512".

I should add that to boot the partition I use the following.

title Windows Boot Manager find --set-root --ignore-cd --ignore-floppies --ignore-oem /bootmgr chainloader /bootmgr

Drive layout.

http://img171.imageshack.us/img171/4301/diskmanagement.jpg http://img573.imageshack.us/img573/3035/diskpart.jpg

Please do the following steps 1.boot to grub4dos commandline use command find to list partition. eg. grub>find and then upload the results. 2.upload you disk mbr(63sec).

r135: grub> find (hd0,0)

grub>geometry drive 0x80(LBA): C/H/S=1024/255/63, Sector Count/Size=1953521664/512

r134: grub> find (hd0,0) (hd0,1) (hd0,2)

grub> geometry drive 0x80(LBA): C/H/S=1024/255/63, Sector Count/Size=1953521664/512 Partition num: 0, active, Filesystem is ntfs, partition type 0x07 Partition num: 1, Filesystem is ntfs, partition type 0x07 Partition num: 2, Filesystem is ntfs, partition type 0x07

I've also attached my bootsect which I got with HDHacker.

Hopefully all of this will help you fix the bug.

Everything seemed normal..

Please report more information about the issue.

There's really not much else to add.

I can boot into Windows with r134 and all earlier builds but I can't with r135.

As the report shows it's unable to find all my partitions when using the find command with r135 and when using the geometry command it fails to display any information about any of the partitions, this even includes the one the find command listed (hd0,0). With r134 it all works perfectly so I can without any doubt say it's the new GPT code you added that's at fault.

So to put it in simple terms r135 outputs: grub> find (hd0,0) grub> geometry drive 0x80(LBA): C/H/S=1024/255/63, Sector Count/Size=1953521664/512

But doesn't display (hd0,1) or (hd0,2) and it doesn't display the file system, partition type or the partition numbers. It just completely fails to read the drive accurately and this I know is not a firmware or BIOS problem because why would r134 and every other build before it still function?

The drive is a Seagate 7200.12 1TB model ST31000528AS. It's running the latest firmware, as is my BIOS.

Looking at your code the error has to either be in this:

if (! rawread (next_partition_drive, 1, 0, SECTOR_SIZE, (unsigned long long)(unsigned int)next_partition_buf, 0xedde0d90))

Or this:

if (*(unsigned long long *)next_partition_buf == 0X5452415020494645LL)

Or this:

if (*next_partition_ext_offset != 0x80)

I'm no programmer but I know that these checks determine how the drive information is read and at the moment it'd appear as though it's read as GPT which would be wrong.

The drive is using MBR so GPT shouldn't be used at all.

I've been trying to make sense of the code. Please keep in mind I'm no programmer but here's what I got.

next_partition_offset, next_partition_ext_offset, next_partition_entry & next_partition_buf are set to their values. Before in r134 there was nothing that altered these values but the GPT check in r135 does:

*next_partition_offset = *(unsigned long )(next_partition_buf + 72);/ Partition entries starting LBA */ *next_partition_entry = *(unsigned long )(next_partition_buf + 80);/ Number of partition entries */ *next_partition_ext_offset = *(unsigned long )(next_partition_buf + 84);/ Size of a partition entry (usually 128) */

Just after you set these values you do an check and return 0 and tell it to move onto the next GPT slice. The issue I think here is what if it's not GPT? You've gone and set these values but you didn't revert them when it failed.

So now look at the code:

/* Read the MBR or the boot sector of the extended partition. */ if (! rawread (next_partition_drive, *next_partition_offset, 0, SECTOR_SIZE, (unsigned long long)(unsigned int)next_partition_buf, 0xedde0d90)) return 0;

Notice it has "*next_partition_offset" which if failed is going to be wrong because of the +72 done by the GPT code. The same goes for all of the other values.

So the issue I think is that the GPT code is throwing off the values because it can't identify the MBR correct.

I managed to compile the source myself with a kit I found online. If I comment out everything between lines 817 to 827 then everything works perfectly, just as it did in r134.

I don't have the knowledge to fix this myself but to me it's now clearly a bug.

To add to the above the wrong offsets would explain why it's only detecting (hd0,0) and it can't display anything about that partitions geometry either.

I hope some of this helps you to resolve the problem.

Thanks.

Thanks.

Could you please upload you disk MBR here?I need to check it. You can use diskrw to save you harddisk mbr eg. diskrw 0 0 63 /s mbr.bin

It doesn't seem to work as it just repeats the same screen over and over and doesn't write the file. I even tried running it as an administrator but that has the same problem.

May I ask though why the MBR is so important as from what I understand its the boot sector that will actually tell you a lot about the sectors?

http://bootmaster.filerecovery.biz/appnote3.html

I've tried installing GRUB a few different ways. Via bootlace, adding it to the exiting boot manager, renaming grldr to bootmgr, using the Microsoft bootsect tool. All of these methods made no difference with r135 but all of them worked when I commented out the GPT code.

I will post some more drive information in a few hours as I've got to get ready for work at the moment. Thanks for your time.

Please test the newest version.Hope it works well.

Unfortunately that didn't work either.

I've created a thread at reboot.pro to see if anyone else with similar hardware can reproduce the same problem.

http://reboot.pro/13836/

I've attached a file with my drive information which should hopefully be a huge help to you.

Here's one other file generated with a rather old program so it may not be as accurate as the one above.

About mbr: http://en.wikipedia.org/wiki/Master_boot_record

There is another way to get your harddisk mbr

First,in windows use fsutil to create a 32KB file. fsutil file createnew c:\mbr.bin 32256

and then boot to grub4dos commandline(with version r134),and enter below commands find --set-root /mbr.bin dd if=(hd0)+63 of=()/mbr.bin

Now the mbr.bin is the backup of your harddisk.

Heres the MBR. I had to get it with HDHacker as your commands instead generated a file that just contained nulls.

That is not help for me.need more sectors. I think your disk is use GPT part first,and then convert to MBR.

That's from the active partition containing the boot files.

I've gave the whole drive output, the bootsector and the complete MBR so there's not much else to give is there? All of this information is from the main partition and Grub4Dos since r135 can't read any of these partitions. Remove the GPT code and it works perfectly fine so I would think the solution until you have enough information is to disable GPT support to maximize compatibility?

The drives only 1TB and it's always been MBR as I've no use for GPT and only use Windows.

May be necessary to add more validation for GPT PART next version.

The GPT Partition table beginning from the second sector of disk. http://en.wikipedia.org/wiki/GUID_Partition_Table

If you does not use GPT PART,you can modify you harddisk second sector,delete string "GPT PART".

That can solve the problem.

Please test the new version 2011-02-15.

I think the problem should be solved.

It works perfect now.

I'm not able to fully understand the changes that were made but I just want to say thank you and to keep up the good work!

Thank you for your test and report too.

New version will check MBR part if the first part type is 0xEE will use GPT part.