Tabela de partição exibida incorretamente dentro das ferramentas de software da partição

Eu gostaria de fazer algum trabalho na sdb3partição:

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

No entanto, as duas ferramentas de particionamento que eu tentei (gParted e KDE Partition Manager) não conseguem encontrar essa partição:

Como entrei nessa situação

Eu estava realizando uma operação de redimensionamento de partição no Gerenciador de partições do KDE. Após 10 segundos, lembrei que também queria que a partição fosse movida para outra unidade. Clicou em Cancelar, 2 horas depois, o KDE Partition Manager ainda estava tentando cancelar a operação. Eu forcei que parasse, então com a ajuda do Testdisk eu consegui recuperar as 3 partições do sdb. Entrou no Windows XP e foi executado chkdsk /fcom êxito em todas as 3 partições NTFS do Windows sdb. No momento, todos eles podem ser montados e usados ​​no Linux e Windows, aparentemente bem.

Como eu faria as três partições aparecerem novamente no software de particionamento?

editar 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

A resposta de Kamil @ https://superuser.com/a/1225632/60373 não fez o truque para mim.

Esqueci de mencionar um pouco importante. Esta máquina possui 3 sistemas operacionais

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

/ dev / sda1 é a partição do Win XP, aparentemente com o carregador do Win8:

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

Isso parece bom para mim, mas ... O Windows 8.1 não carrega. Novamente, a partição Win8 (também conhecida como sdb3 ) é montada bem no Win XP e Linux. Pesquisando na Internet o código de erro "0xc000000e" não fornece uma resposta clara para o meu problema.

Eu acho que a tabela de partição MBR está quebrada. Enquanto o fdisk é capaz de reconhecer partições, a partição em si está presa. O KDE Partition Manager e o GParted contam com o libparted para detecção de partições, portanto, mostram informações incorretas.

Sugiro recriar uma tabela de partição com exatamente os mesmos limites de partição de antes.

Você pode conferir minha tentativa aqui: https://stikonas.eu/files/sdb.mbr.new

Observe também que suas partições não estão alinhadas ao longo dos limites do MiB. Provavelmente não importa muito para discos HDD antigos, mas isso importa para SSD.

Edit:
Infelizmente esta resposta não resolve o problema do OP . Não vou excluí-lo (pelo menos por enquanto). Ele documenta uma tentativa fracassada que tem algum valor educacional. Também impedirá que outras pessoas publiquem a mesma solução possível.

(A edição termina aqui, a resposta original está abaixo).

Sua situação pode ser semelhante a isso , mas um pouco diferente. Admito que não posso explicar exatamente como as ações que você descreveu podem ter causado isso, no entanto, acho que minha teoria a seguir é plausível .

Na questão vinculada, havia realmente um super-disquete (ou seja, um sistema de arquivos em todo o dispositivo, sem tabela de partição), mas a maioria dos programas (incluindo o Windows) detectou sua tabela de partição (inválida) primeiro.

Você tem uma tabela de partição válida e a maioria dos programas deve detectá-la (como o Windows). Ainda assim, o KDE Partition Manager acha que seu disco é um super-disquete com o sistema de arquivos NTFS em todo o dispositivo. Parece que ele tenta detectar primeiro o sistema de arquivos super-flexível e, se for bem-sucedido, pula testes adicionais. Eu acho que algumas partes da /dev/sdbMBR enganar o Partition Manager.

Se você não inicializar a partir de/dev/sdb (ou seja, o código de inicialização não é totalmente utilizado, você inicializa /dev/sdasomente e com certeza), você pode escrever zeros na área de código de inicialização do /dev/sdbMBR. Na minha resposta à pergunta vinculada, há um gráfico que compara o MBR ao 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
───────────┴─────────────┴─────────────

Deve ser suficiente gravar zeros nos primeiros 84 bytes do disco para impedir que qualquer ferramenta encontre a assinatura NTFS na (suposta) super-disquete.

No 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

Então (re) inicie o seu KDE Partition Manager e veja se ele ajudou. Caso contrário, é aconselhável reverter a alteração, caso você tenha cometido um erro pensando que o código de autoinicialização não /dev/sdbera importante.

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