[SOLVED] Help to Repair Partition Table Overlaps

rknichols · 08-03-2015, 11:54 PM

Quote:

Originally Posted by syg00

No, that's the fun part.
Because of the initial install as a primary, it has an entry in the partition table, so will be found ok. fdisk shows it as a logical because of the existence of that extended. Bad assumption on the (fdisk and parted too I think) coders part.

Why do you think there was an initial Linux install in a primary partition? Linux will install quite happily in a logical partition. Neither fdisk nor sfdisk show any primary partition starting at that offset. The only place that offset occurs is in the first header inside the extended partition. It does not occur anywhere in the primary partition table.

rknichols · 08-04-2015, 12:16 AM

Quote:

Originally Posted by jefro

It is possible that a very old program made the issue and has been like this for years.

It is common for Windows reinstalls/repairs to mangle a partition table in just this way, apparently due to the Windows installer having slightly different partitioning rules than does Linux. If you search for "omitting empty partition" and follow some of the referenced discussion, you'll find multiple examples, including one very similar to the current case.

weebo · 08-04-2015, 05:40 AM

Quote:

Originally Posted by jefro

It is possible that a very old program made the issue and has been like this for years.

I do not think that this is the case but, of course, I cannot remember the install sequence - that was many years ago. The machine was healthy until very recently. After reading through the last few posts I would be 90 percent certain that a windows 'repair' caused the irregularities.

Steve.

weebo · 08-06-2015, 06:52 AM

Quote:

Originally Posted by rknichols

I would not recommend clonezilla or any "smart" imaging tool to copy a drive with known structure errors. I would just make a partition at least 200GB in size and use dd to copy the source drive to it, byte-for-byte. Assuming your new partition is /dev/sdb1, that would be

Code:

dd if=/dev/sda of=/dev/sdb1 bs=1M

That should be done while booted from a rescue disk so that no partitions on the source drive are mounted. Be absolutely sure you get the source ("if=") and destination ("of=") parameters correct, since dd will be quite happy to copy the empty new drive back to the original. The "bs=1M" parameter is fairly arbitrary. You just want a blocksize a good deal larger than the default 512 bytes for efficiency.

BTW, that command is going to take a few hours to complete, quite a few if that new drive is on a USB 2.0 interface.

Using fdisk to delete partition 3 is straightforward. You just need the "d" command, then the partition number, then "w" to write out the result and exit. I've put the part you type in red.

Code:

# fdisk /dev/sda
.
.
.
Command (m for help): d
Partition number (1-4): 3

Command (m for help): w

Again, be sure you're working on the right disk, though a mistake there is fairly easy to recover from.

Ok, I did as you described above. After the partition3 delete, fdisk reported that the kernel was still using the old partition table and the new one would be used on reboot so I rebooted - now on startup the system will not boot and I get dropped into GRUB RESCUE shell.

from grub rescue:

ls gives:

Code:

(hd0) (hd0,6) (hd0,5) (hd0,1) (fd0)

set gives:

Code:

prefix=(hd0,6)/boot/grub
root=hd0,6

Running testdisk finds the following partitions:

Code:

    Partition               Start        End       Size in sectors
* HPFS - NTFS              0   1   1   6091 254 63    97867917
L Linux                 6092   2   1  23629 254 63   281747844
L Linux Swap           23630   1   1  24192 254 63     9044532
L FAT16 LBA            242193  1   1  24319 254 63     2040192

So as not to make a mistake can you guide me with the next step?

Many thanks,
Steve.

rknichols · 08-06-2015, 10:32 AM

Did you make the backup image that was advised?

What error message do you get prior to going to the GRUB rescue shell?

Was this system able to boot prior to deleting partition 3? I ask because I can't imagine why deleting a primary partition with no recognizable filesystem would cause a system to fail to boot.

Does "fdisk -lu /dev/sda" still still give that "omitting empty partition" warning? Does the output still look the same as it was (but without partition 3, of course)? I'm guessing that perhaps fdisk quietly deleted that bogus empty partition and that changed the partition numbering that GRUB sees. (Thinking...) Yes, that would explain why GRUB is referencing partition 6 when your Linux installation is on partition 5.

Unfortunately, I have almost no knowledge about GRUB 2 (aside from knowing that it's partition numbers start at "1" rather than "0"), but what I've found suggests doing

Code:

set prefix=(hd0,5)/grub
set root=(hd0,5)
insmod normal
normal

weebo · 08-06-2015, 11:17 AM

Hi there,

Yes I did make an image as per your instructions. I couldn't examine it, but since I followed the instructions to the letter and the process took a couple (or four!) hours and the original disk was intact afterwards I am assuming it was sucessful.

The message just prior to the grub rescue shell is: error unknown filesytem.

Yes the system booted nicely prior to the deletion of partition 3, don't forget that the original problem from my post#1 was that whilst it would boot into Linux it would not boot into XP, showing only a brief XP splash screen.

The "omitting empty partition warning" is no longer there which I am taking as a good thing.
I will give the output of fdisk -lu /dev/sda in the next post as I am writing this on another machine.

What time zone are you in? I'm on GMT.

Best,
Steve.

PS "aside from knowing that it's partition numbers start at "1" rather than "0"..." That's slightly more than I know so I'm happy to listen!!!!

weebo · 08-06-2015, 11:19 AM

Here's the fdisk output:

Code:

sudo fdisk -lu /dev/sda

Disk /dev/sda: 200.0 GB, 200048565760 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390719855 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc8afc8af

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    97867979    48933958+   7  HPFS/NTFS/exFAT
/dev/sda2        97867980   390700799   146416410    f  W95 Ext'd (LBA)
/dev/sda5        97868106   379615949   140873922   83  Linux
/dev/sda6       379616013   388660544     4522266   82  Linux swap / Solaris

Cheers!

rknichols · 08-06-2015, 12:12 PM

I'm on US Central Time, right now 5 hours behind you. Thu Aug 6 11:08:10 CDT 2015

As I suspected, fdisk got rid of that empty partition, which is what GRUB considered partition 5, making your Linux and swap partitions numbered 6 and 7, respectively.

Changing the GRUB prefix and root to partition 5, as I indicated above, should allow the machine to boot. You will then need to re-setup the GRUB loader, and I'm really the wrong person to be instructing you on that for GRUB 2.

weebo · 08-06-2015, 01:50 PM

That makes a lot of sense, I'll try it and let you know how it goes. One step at a time eh? Once the machine is booting nicely again I'll start looking into setting grub up properly.

Nice sunny evening here in the English hills

Cheers,
Steve.

weebo · 08-06-2015, 02:40 PM

OK, so far so good; the set prefix workaround has got the system booted into Linux, it won't however boot into XP which is how I was before the partition table was modified.
I will now start to look into how to get grub working again. It seems as if I have gone backwards slightly at this point in time but let's see....

So apart from repairing grub somehow, the question remains as to why XP won't boot. I guess one thing we do know for sure now is that it was not due to the oddly places FAT16 partition.

All help still most gratefully received!

Steve.

rknichols · 08-06-2015, 06:01 PM

Since testdisk seems to think it can recover that FAT16 partition, I'd be inclined to let it do that, write out the updated partition table, then see if the resulting sda7 partition looks like it contains a filesystem ("file -s /dev/sda7"). Perhaps there is something in there that Windows XP expects to see. If you do find a filesystem there, you could mount it read-only in Linux and see what it contains.

If you get a message that a reboot is needed to see the new partition, you can try running "partprobe /dev/sda" and see if that might be sufficient.

weebo · 08-06-2015, 06:13 PM

Quote:

Originally Posted by rknichols

Since testdisk seems to think it can recover that FAT16 partition, I'd be inclined to let it do that, write out the updated partition table, then see if the resulting sda7 partition looks like it contains a filesystem ("file -s /dev/sda7"). Perhaps there is something in there that Windows XP expects to see. If you do find a filesystem there, you could mount it read-only in Linux and see what it contains.

If you get a message that a reboot is needed to see the new partition, you can try running "partprobe /dev/sda" and see if that might be sufficient.

Thanks for this, interesting ideas for sure. I'm working away from home for the next two days but will give it all a try on my return.

Steve.

weebo · 08-12-2015, 07:04 AM

It's been a few days but I've got back to this problem...

I let Testdisk find the Fat16 partition and write it to the partition table.
The output of file -s/dev/sda7 is "data".

I should add that after reinstating the FAT16 partition (partition 7) the grub rescue set prefix workaround no longer works even after deleting partition 7....

Should repost this somewhere else to get help with grub?

Steve.

rknichols · 08-12-2015, 10:37 AM

Quote:

Originally Posted by weebo

I let Testdisk find the Fat16 partition and write it to the partition table.
The output of file -s/dev/sda7 is "data".

So, testdisk did not try to repair the broken filesystem. No great surprise there. If there's a backup header, "fsck.msdos -r /dev/sda7" might be able to repair it.

Quote:

I should add that after reinstating the FAT16 partition (partition 7) the grub rescue set prefix workaround no longer works even after deleting partition 7....

That makes no sense at all. What does "sfdisk -d /dev/sda" show, both with and without partition 7 present?

Quote:

Should repost this somewhere else to get help with grub?

Probably, depending on what sfdisk shows for the partitioning now.

weebo · 08-16-2015, 03:10 PM

Great news - I can report that it's fixed and all is well.

I read this:
https://help.ubuntu.com/community/BootSectorFix
And followed the suggestion to use the Ubuntu Boot-Repair disk and see what it did... It worked very well and sorted out the Grub problem so I could boot into Linux - Yipee!!!!

Then I had a good read of the following advice on how to repair the XP bootloader with the windows installation disk:
https://help.ubuntu.com/community/Re...ta/7Bootloader

Since I had an image of the disk I figured that the worst that could happen was having to load the image to get back to where I was but no need to worry - that worked too!!

So I have a system that works nicely again - job done.

Now the important bit; I thank you rknichols for your excellent friendly and very useful help, cheers matey! Your support gave me confidence and also in going through the steps you so clearly outlined for me I learned a fair bit about partition tables

All the very best to you,
Steve.