Por que você não:
sudo losetup /dev/loop0 /path/to/disk.img
mkdir /mnt/image
sudo mount /dev/loop0 /mnt/image
Eu tenho uma imagem da minha partição home ( /dev/sda3 ), que eu criei usando o comando "dd".
dd if=/dev/sda3 of=/path/to/disk.img
Eu deletei a partição home via gparted para aumentar minha partição /dev/root . Em seguida, recriou a partição /dev/sda3 , que é menor em tamanho do que a que copiei para a imagem.
Eu queria saber desde que eu tenho um HDD externo de 2 TB, poderia ser possível montar minha imagem de backup no disco rígido externo e copie os arquivos para o diretório /home . Como o disco rígido externo já estaria em um "estado montado", não tenho certeza se isso é uma boa ideia, montando em um dispositivo montado.
Eu tentei:
mount -t ext4 /path/to/disk.img /mng/image -o loop
Ele me deu um erro fs (errado tipo fs, má opção, bad superblock em dev / loop / 0)
Então eu fiz
dmesg | tail
quais saídas:
EXT4-fs (loop0) : bad geometry: block count 29009610 exceeds size of defice (1679229 blocks)
Não tenho ideia do que fazer, quero restaurar meus /home dados da imagem da qual fiz o backup.
[Atualizar] : * O disk.image está na minha unidade flash USB de 16GB. O tamanho da imagem é de cerca de 6 GB. A imagem foi criada a partir de uma partição excluída com cerca de 100 GB e agora reduzida para cerca de 80 GB.
[Atualizar] : Eu tentei isso hoje: LQWiki: Alguns exemplos de dd diz:
You don't want to tell a drive it is bigger than it really is by writing a partition table from a larger drive to a smaller drive. The first 63 sectors of a drive are empty, except sector 1, the MBR.
dd if=/dev/sda skip=2 of=/dev/sdb seek=2 bs=4k conv=noerror
Eu tentei montar /dev/sda3 to /home .
dmesg | tail gera um erro "descritores de grupo corrompidos!"
Então eu tentei:
fsck.ext4 -y -f /dev/sda3
Produz uma grande quantidade de problemas fixos e milhões de números diminuindo na velocidade da luz.
Depois disso, montei com sucesso /dev/sda3 to /home , mas não havia dados no diretório inicial. Apenas algum diretório chamado "lost + found", que também está vazio.
Por que você não:
sudo losetup /dev/loop0 /path/to/disk.img
mkdir /mnt/image
sudo mount /dev/loop0 /mnt/image
Tente truncar o arquivo para a contagem de blocos excedente e, em seguida, remonte. Na sua situação:
EXT4-fs (loop0): geometria incorreta: a contagem de blocos 29009610 excede o tamanho do recurso (1679229 blocos)
truncate -o -s 29009610 /path/to/disk.img
mount -o loop /path/to/disk.img /mng/image
Flavio
Eu sei que essa é uma pergunta antiga, mas acabei de encontrar esse mesmo problema há dois dias e consegui resolver um pouco o problema.
Este problema ocorre basicamente quando, de alguma maneira ou de outra, uma imagem do sistema de arquivos ext2 / 3/4 não é totalmente copiada para um arquivo de imagem, essencialmente deixando um pedaço de dados faltando no final. Por causa disso, você não poderá recuperar todos os arquivos que existiam na imagem original, a menos que, por algum milagre, nenhum dado de arquivo tenha sido armazenado na parte que faltava na imagem.
No meu caso, não consegui montar a imagem, mas existe um utilitário que varre as imagens do sistema de arquivos ext2 / 3/4 e despeja todos os arquivos encontrados em um local especificado:
bash$ losetup -f ./corrupted.img # mounts to /dev/loop0
bash$ sudo debugfs -c /dev/loop0
debugfs: rdump / /path/to/dump/files/
debugfs: quit
O comando rdump recebe dois argumentos: caminho dentro da imagem corrompida para procurar recursivamente por arquivos, e o caminho no sistema de arquivos nativo para salvar os arquivos. Todos os arquivos que não puderam ser recuperados serão criados com um tamanho de 0 bytes.
Você provavelmente precisará dos arquivos, pois o debugfs é executado como root.