Tudo isso começou quando um disco que eu usei para arquivar alguns dados de repente não montou mais.
Quando eu tentei com o terminal, é dito:
"O tamanho do sistema de arquivos (de acordo com o superbloco) é de 732566128 blocos
O tamanho físico do dispositivo é 732565864 blocos
O superbloco ou a tabela de partições provavelmente estará corrompida! "
Quando tento montá-lo com o Gnome-Disk-Utility, recebo este erro:
"Erro ao montar / dev / dm-6 em / media / user1 / 3PAB:
Linha de comando 'mount -t "ext3" -o "uhelper = udisks2, nodev, nosuid" "/ dev / dm-6" "/ media / user1 / 3PAB"' saiu com status de saída diferente de zero 32:
mount: errado tipo fs, má opção, bad superblock em / dev / mapper / luks-c4ebeef5-7537-417e-b63b-fedc99561677, falta de página de códigos ou programa auxiliar, ou outro erro
Em alguns casos, informações úteis são encontradas no syslog - tente
dmesg | cauda ou mais.
(udisks-error-quark, 0) "
Além disso, o syslog me deu isto:
"Dec 12 15:12:44 d8d kernel: [47.862779] EXT4-fs (dm-6): montando o sistema de arquivos ext3 usando o subsistema ext4
Dec 12 15:12:44 d8d kernel: [47.863025] EXT4-fs (dm-6): geometria incorreta: a contagem de blocos 732566128 excede o tamanho do dispositivo (blocos 732565864) "
Eu não entendo porque ele diz "montagem do sistema de arquivos ext3 usando o subsistema ext4", quando eu sei que é ext3 e "lsblk -f" confirma isso.
Embora fdisk estados "dados básicos da Microsoft", mas eu já procurei no google e sei que isso é um bug.
Eu tentei "fsck" e "fsck -f" mais de uma vez, mas sem sorte.
Quando comprei esse disco, na verdade comprei duas unidades (mesmo tamanho, mesma marca, etc.) e formatei da mesma maneira e criptografei as duas com o LUKS também.
Apenas os dados que coloquei em cada um deles eram diferentes.
Então, depois de pesquisar por algum tempo, executei esses comandos em ambos os discos para poder ver as diferenças e salvar todos os resultados em arquivos txt, caso necessário:
sfdisk -luS / dev / sdg
fdisk -l / dev / sdg
tune2fs -l / dev / mapper / PAB
Como resultado, descobri que o tamanho do superbloco estava correto, então concluí que a partição do primeiro disco misteriosamente mudou para alguns blocos antes, criando assim essa situação.
Setores finais do dispositivo inicial
/ dev / sdb1 2048 5860533134 5860531087 (correto; disco 2)
/ dev / sdg1 2048 5860531021 5860528974 (incorreto; disco 1)
Então, eu pensei que poderia resolver isso criando manualmente uma nova tabela de partição usando o parted e definindo o final no setor correto.
Eu fiz isso, mas agora a nova partição não é reconhecida como uma partição LUKS.
E para não piorar as coisas, eu fiz este pedido de ajuda.
É possível recuperar os dados?
ADDING TESTDISK LOG:
/ dev / sdg: LBA, HPA, LBA48, DCO support
/ dev / sdg: size 5860531055 setores
/ dev / sdg: user_max 5860531055 setores
/ dev / sdg: native_max 5860533168 setores
/ dev / sdg: dco 5860533168 setores
Usando o código de idioma 'en_US.UTF-8'.
Qua Dez 14 01:02:53 2016
Linha de comando: TestDisk / debug / log / dev / sdg
TestDisk 6.14, Data Recovery Utility, julho de 2013
SO: Linux, kernel 3.16.0-4-amd64 (# 1 SMP Debian 3.16.36-1 + deb8u2 (2016-10-19)) x86_64
Compilador: GCC 4.9
Data de compilação: 2014-10-19T15: 35: 24
ext2fs lib: 1.42.12, ntfs lib: libntfs-3g, reiserfs lib: nenhum, ewf lib: none
Lista de discos rígidos
Disco / dev / sdg - 3000 GB / 2794 GiB - CHS 364801 255 63, tamanho do setor = 512 - ST3000DM001-1CH166, S / N: Z1F0R2CP, FW: CC43
/ dev / sdg: presente da área protegida do host (HPA).
Tipo de tabela de partição (auto): EFI GPT
Disco / dev / sdg - 3000 GB / 2794 GiB - ST3000DM001-1CH166
Tipo de tabela de partição: EFI GPT
Analisar disco / dev / sdg - 3000 GB / 2794 GiB - CHS 364801 255 63
hdr_size = 92
hdr_lba_self = 1
hdr_lba_alt = 5860531054 (esperado 5860531054)
hdr_lba_start = 34
hdr_lba_end = 5860531021
hdr_lba_table = 2
hdr_entries = 128
hdr_entsz = 128
Estrutura de partições atual:
1 P Desconhecido 2048 5860531021 5860528974 [PABnew]