Questão Tabela de partição estranho


Recebi um disco rígido para reparar / extrair dados. Este disco rígido já foi o disco rígido de um computador que tinha windows e linux instalados (usando o grub para alternar entre dois). Inicializar a partir do disco rígido não é mais possível. Quando conectado ao linux, 4 partições são encontradas (/dev/sdb[1256]), se apenas /dev/sdb1 pode ser lido. /dev/sdb1 é a partição-grub, enquanto /dev/sdb5 foi identificado como partição-swap por blkid (pode ter sido outro programa, vou verificar isso). Montando as partições 2 e 6 dá erros, var/log/syslog diz algo sobre um superbloco ruim.
Ainda assim, o resultado mais irritante fdisk -l, que imprime a tabela de partições AFAIK.

Device    Start    End        Type
/dev/sdb1     2048  19531775  83 linux
/dev/sdb2 19533822 625141759   5 extended
/dev/sdb5 19533824  36304895  82 linux swap 
/dev/sdb6 36306944 625141759  83 linux

(1 setor é igual a 512 bytes, parte da saída foi removida por mim. Vou adicioná-lo se necessário)

Se bem entendi, algo está errado com a tabela de partições. De alguma forma, a partição 2 está no mesmo local das partições 5 e 6, o que pode explicar os erros de montagem. (Eu perguntarei qual sistema operacional realmente foi usado neste disco rígido).


2


origem


As únicas partições aqui que potencialmente poderiam conter dados são sdb1 e sdb6 (a informação da partição é dada habilmente pela resposta de grawity), e não há partições do Windows aqui para recuperar dados. Embora eu não possa dizer com certeza, o sdb1 era provavelmente root (/) e sdb6 provavelmente era home (/ home), então o mais recente é provavelmente o mais importante. Se possível, desde que você está recebendo erros, eu dd essas 2 partições para arquivos, monte os arquivos e tente a recuperação lá. - acejavelin
"/dev/sdb1 é a partição do grub "- Não, eu não acho que seja. É sobre 9.5GiB, o que sugere que é o sistema de arquivos raiz (contendo os programas OS +, mas não os documentos e mídia). Ok, o sistema de arquivos raiz este caso Além disso contém grub, mas para mim "partição-grub" implica que só contém grub. - marcelm
@marcelm If /dev/sdb1 seria a partição raiz, haveria diretórios como bin, var, etc e outros. Eu só dei uma olhada rápida, mas eu não vi isso. Eu rapidamente decidi que /dev/sdb1 Não havia sistema de arquivos raiz porque havia muitos arquivos contendo "grub" no diretório mais acima. Mas é claro que isso não diz que estou certo, até agora eu só vi um número limitado de distribuições linux. Eu vou dar uma boa olhada depois. Obrigado. - AidenPearce
Para verificar a unidade (possivelmente brutalizado) Partições NTFS, veja minha resposta aqui: askubuntu.com/a/776317/271 - Andrea Lazzarotto


Respostas:


Se subestimo corretamente, algo está errado com a tabela de partições. De alguma forma, a partição 2 está no mesmo local das partições 5 e 6, o que pode explicar os erros de montagem.

Isto é normal. A tabela de partições MBR da era do MS-DOS só pode conter 4 partições, então é costume fazer a última uma partição "estendida", em que partições "lógicas" adicionais são aninhadas.

(O Linux sempre numera as partições lógicas começando com 5+, e enquanto os nomes fdisk -l na verdade, eles também seguem a mesma numeração.)

(Enquanto estiver no tópico, não se esqueça de que existem outras tabelas de partição como a GPT. O fdisk 2.23 entende o GPT, mas versões mais antigas não.)

Observe também que os tipos de partição nem sempre correspondem aos dados reais internos. Não é impossível que o proprietário tenha decidido usar sdb5 para dados e sdb6 para swap, mas esqueceu de atualizar os tipos de partição MBR (que o Linux ignora, de qualquer forma).

Como faço para obter esses arquivos do disco rígido ou (melhor) alterar o disco rígido para que o Linux possa montar todas as partições

Experimentar photorec.

Meu primeiro pensamento foi fazer um backup com o dd e então deixar um fsck rodar em / dev / sdb

Fazer um backup é uma boa ideia. Tentando executar fsck em algo que é não é um FS não fará nada de útil. /dev/sdb1 ou /dev/sdb6 seriam melhores alvos para isso, já que eles contêm sistemas de arquivos.


7



Obrigado pela sua resposta rápida. É bom saber que a tabela de partição está ok (você aprende algo novo todos os dias :)). Vou tentar o software de recuperação fotorec e outros (também existem vídeos nessa unidade) após o término do backup, para não esquecer o fsck on /dev/sdb6. - AidenPearce
Eu sugeriria ir com testdisk antes de esculpir com photorec. O Testdisk entende os sistemas de arquivos, por isso deve-se tentar primeiro obter um resultado melhor. - Andrea Lazzarotto


A tabela de partições exibida é de um puro Sistema Linux: não há nenhum vestígio de Windows nele. Então, dado que você declarou:

Este disco rígido já foi o disco rígido de um computador que tinha windows e linux instalados ...

talvez o cara que deu a você estava certo quando ele disse ...

Além disso, a pessoa que me deu o disco rígido agora está pensando se ele me deu o caminho certo.

Os arquivos do usuário estão em /home/, que é provável que seja partição /dev/sdb6. Não há necessidade de usar algo tão complexo quanto photorece, possivelmente, você pode restaurar a partição para seu estado de funcionamento completo, de uma maneira alternativa. Você pode, por favor, indicar exatamente qual mensagem de erro é obtida ao tentar montar a partição /dev/sdb6? Se for apenas uma questão de um superbloco ruim, isso pode ser facilmente curado:

  1. Verifique o sistema de arquivos com (você pode ter que refazer isso com ext2 ou ext3, não está claro a partir do acima qual sistema de arquivos estava sendo usado),

     sudo fsck.ext4 -v /dev/sdb6
    
  2. Se o superbloco é realmente corrupto, então você terá uma saída como

    fsck /dev/sdb6
    fsck 1.41.4 (27-Jan-2009)
    e2fsck 1.41.4 (27-Jan-2009)
    fsck.ext4: Group descriptors look bad... trying backup blocks...
    fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb6
    
    The superblock could not be read or does not describe a correct ext4
    filesystem.  If the device is valid and it really contains an ext4
    filesystem (and not swap or ufs or something else), then the superblock
    is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 /device
    
  3. Vamos descobrir onde estão os superblocos de backup

    sudo mke2fs -n /dev/sdb6
    

    No bootom de uma saída longa, você encontrará algo como:

    Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
    
  4. E agora, finalmente, corrija-o substituindo o superbloco defeituoso por um (qualquer um) dos backups:

    sudo e2fsck -b block_number /dev/sb6
    

Reinicie, e você deve ser bom para ir. Se não, tente um superbloco diferente. Como eu disse, E se esta é a razão pela qual você não pode montar a partição /dev/sdb6, tudo isso é muito mais fácil do que usar photorecAlém disso, você irá restaurar o disco e suas partições ao estado original.


-1



«Não há nenhum vestígio de Windows nele» Você está assumindo que a tabela de partição é confiável e não foi sobrescrita. Pode ser uma suposição bastante forte. No entanto, o OP deve varrer a unidade em busca de sobras de NTFS. :) - Andrea Lazzarotto
Não existe um superbloco em NTFS (bem, sim, o MFT, mas não é o mesmo). Se o OP quiser verificar a presença de rastreios NTFS, a tabela de partição não deverá ser confiável cegamente. - Andrea Lazzarotto
Sim, e desenvolvi um software de reconstrução NTFS forense. Isso não muda o fato de que sua confiança na tabela de partições sozinha é uma abordagem bastante ingênua. Você não pode determinar que não há nenhum rastro de um sistema de arquivos NTFS apenas porque a tabela de partição não o lista. Se você não confia neste fato (óbvio), você pode conferir Brian Carrier. Análise forense do sistema de arquivos. ISBN 0321268172. ou Harlan Carvey. Windows Forensics e Recuperação de Incidentes. ISBN 0321200985. - Andrea Lazzarotto