Partition table incorrectly displayed inside partition software tools

Question

I would like to do some work on sdb3 partition:

sudo fdisk -l

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
16 heads, 63 sectors/track, 1938021 cylinders, total 1953525168 sectors 
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x2052474d

   Device Boot      Start         End      Blocks   Id  System 
   /dev/sdb1              63   549971855   274985896+   7  HPFS/NTFS/exFAT 
   Partition 1 does not start on physical sector boundary.
   /dev/sdb2       549971856  1470063167   460045656    7  HPFS/NTFS/exFAT 
   /dev/sdb3   *  1470063168  1810175471   170056152    7  HPFS/NTFS/exFAT

However both partitioning tools that I have tried (gParted and KDE Partition Manager) are unable to find that partition:

How I got into this situation

I was doing a partition-resizing operation from KDE partition Manager. After 10 seconds into it I remembered that I also wanted that partition moved to another drive. Clicked Cancel, 2 hours later KDE Partition Manager was still trying to cancel the operation. I have forced stopped it, then with the help of Testdisk I was able to recover the 3 partitions of sdb. Went into Windows XP and successfully ran chkdsk /f on all of the 3 NTFS partitions of sdb. Right now they can all be mounted and used in Linux and Windows apparently fine.

How would I go about making the 3 partitions show up again in the partitioning software?

edit 1

kellogs-PC kellogs # lsblk /dev/sdb
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb      8:16   0 931,5G  0 disk 
├─sdb1   8:17   0 262,3G  0 part /media/kellogs/downloads 2
├─sdb2   8:18   0 438,8G  0 part /media/kellogs/para backup
└─sdb3   8:19   0 162,2G  0 part /media/kellogs/Win8

edit2

Kamil's answer @ https://superuser.com/a/1225632/60373 did not do the trick for me.

Forgot to mention about an important bit. This machine has 3 OSes

/dev/sda - Windows XP, Linux /dev/sdb - Windows 8.1

/dev/sda1 is the Win XP partition, apparently with Win8's loader on it:

kellogs-PC kellogs # update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
  No volume groups found
Found Windows 8 (loader) on /dev/sda1
done

This looks fine to me, but... Windows 8.1 won't load. Again, the Win8 (a.k.a. sdb3) partition gets mounted fine from within Win XP and Linux. Searching the internet for the error code "0xc000000e" does not give me a clear answer to my problem.

Answer 1

I think MBR partition table is broken. While fdisk is able to recognize partitions, parted itself is stuck. Both KDE Partition Manager and GParted rely on libparted for partition detection, so show incorrect info.

I suggest recreating a partition table with exact same partition boundaries as before.

You can check my attempt here: https://stikonas.eu/files/sdb.mbr.new

Also note that your partitions are not aligned along MiB boundaries. Probably doesn't matter too much for old HDD disks but it would matter for SSD.

Answer 2

Edit:
Unfortunately this answer doesn't solve the OP's problem. I won't delete it though (at least for now). It documents a failed attempt which has some educational value. It will also prevent others from posting the same possible solution.

(Edit ends here, the original answer is below).

---

Your situation may be similar to this, yet somewhat different. I admit I cannot explain exactly how the actions you described may have caused this, nevertheless I think my following theory is plausible.

In the linked question there really was a superfloppy (i.e. a filesystem on the entire device, no partition table) but most programs (including Windows) detected its (invalid) partition table first.

You have a valid partition table and most programs should detect it (like Windows does). Still KDE Partition Manager thinks your disk is a superfloppy with NTFS filesystem on the entire device. It looks like it tries to detect superfloppy filesystem first and if it succeeds it skips additional tests. I guess some parts of /dev/sdb MBR mislead your Partition Manager.

If you don't boot from /dev/sdb (i.e. the bootstrap code there is totally unused, you boot from /dev/sda only and for sure) you may write zeros to the bootstrap code area of /dev/sdb MBR. In my answer to the linked question there is a chart which compares MBR to NTFS VBR:

    MBR    │ byte offset │  NTFS VBR
           │  hex / dec  │
───────────┼─────────────┼─────────────
           │ 0x000 / 000 │ mainly NTFS
 bootstrap │      …      │  metadata
   code    ├─────────────┼─────────────
           │ 0x054 / 084 │
           │      …      │  bootstrap
───────────┼─────────────┤    code
 partition │ 0x1BE / 446 │
   table   │      …      │
───────────┼─────────────┼─────────────
   0x55    │ 0x1FE / 510 │    0x55
   0xAA    │ 0x1FF / 511 │    0xAA
───────────┴─────────────┴─────────────

It should be enough to write zeros to the first 84 bytes of the disk to prevent any tool from finding NTFS signature on the (alleged) superfloppy.

In Linux:

# making backup of the entire MBR just in case
dd if=/dev/sdb of=~/sdb.mbr.backup bs=512 count=1

# zeroing alleged NTFS metadata, use 'bs=446' to zero the entire bootstrap code of MBR
dd if=/dev/zero of=/dev/sdb bs=84 count=1
sync

Then (re)start your KDE Partition Manager and see if it helped. If it didn't, it's wise to revert the change just in case you made a mistake thinking the bootstrap code in /dev/sdb was unimportant.

# reverting
dd if=~/sdb.mbr.backup of=/dev/sdb
sync