Sintaxe da opção 'offset' de 'e2fsck'

1

Em esta resposta , o usuário @psusi mostra um uso de e2fsck que eu não encontrei no documentação: e2fsck /dev/sdc1?offset=2048 .

Estou tentando usá-lo para verificar um dispositivo (manualmente com falha e removido) de uma matriz de ataque. Resumindo: Eu sei que a partir do offset 67108864 do / dev / sdb2 existe um sistema de arquivos ext4, que não foi devidamente desmontado. Eu tentei o seguinte (sempre revertendo /dev/sdb2 para o mesmo conteúdo entre testes diferentes).

  1. A execução de mount /dev/sdb2 -o loop,offset=67108864 /tmp/mnt funciona bem e posso ver usando dmesg | tail que ele excluiu 5 inodes órfãos, recuperou totalmente o sistema de arquivos e o montou:

    EXT4-fs: 5 orphan inodes deleted
    EXT4-fs: recovery complete
    EXT4-fs: mounted filesystem with ordered data mode. Opts: (null)
    
  2. Da mesma forma, losetup /dev/loop0 --offset 67108864 /dev/sdb2 && e2fsck -n /dev/loop0 :

    root: recovering journal
    root: Clearing orphaned inode 1179687 (uid=1000, gid=1000, mode=0100600, size=16384)
    root: Clearing orphaned inode 1179686 (uid=1000, gid=1000, mode=0100600, size=16384)
    root: Clearing orphaned inode 1179685 (uid=1000, gid=1000, mode=0100600, size=32768)
    root: Clearing orphaned inode 1179684 (uid=1000, gid=1000, mode=0100600, size=32768)
    root: Clearing orphaned inode 1179683 (uid=1000, gid=1000, mode=0100600, size=65536)
    root: clean, 225936/4882432 files, 2664100/19514624 blocks
    
  3. Eu achei que e2fsck -p /dev/sdb2?offset=67108864 seria equivalente à abordagem acima (usando losetup ), mas em vez disso eu obtenho:

    root: recovering journal
    e2fsck: Bad magic number in super-block while trying to re-open root
    root: ********** WARNING: Filesystem still has errors **********
    

    Tenho certeza de que e2fsck encontra a partição porque, se eu colocar o valor incorreto no deslocamento (por exemplo, 0), recebo um erro informando que o sistema de arquivos não foi encontrado. Além disso, se eu usar e2fsck -p /dev/sdb2?offset=67108864 depois de qualquer uma das abordagens 1 ou 2, ele imprime root: clean, ... .

Gostaria de saber se alguém poderia me indicar a documentação da opção offset de e2fsck ou me ajudar a entender o que ela faz exatamente e como isso difere da montagem do dispositivo de loopback com um determinado deslocamento.

Obrigado.

EDIT: informações adicionais. Eu posso reproduzir esse comportamento da seguinte maneira:

dd if=/dev/zero of=/tmp/disk bs=1M count=100
mkfs -t ext4 -E offset=70000000 /tmp/disk
sudo mount -o loop,offset=70000000 /tmp/disk /mnt/
ps > /mnt/test
cp /tmp/disk /tmp/disk2
cp /tmp/disk2 /tmp/disk2.copy
sudo umount /mnt 
e2fsck -p /tmp/disk2?offset=70000000
# /tmp/disk2: recovering journal
# e2fsck: Bad magic number in super-block while trying to re-open /tmp/disk2
# /tmp/disk2: ********** WARNING: Filesystem still has errors **********
sudo mount -o loop,offset=70000000 /tmp/disk2.copy /mnt/
dmesg | tail
# [240760.866274] EXT4-fs (loop3): mounted filesystem with ordered data mode. Opts: (null)
# [240770.516865] EXT4-fs (loop3): recovery complete
# [240770.516869] EXT4-fs (loop3): mounted filesystem with ordered data mode. Opts: (null)
sudo umount /mnt
e2fsck -n /tmp/disk2?offset=70000000
# e2fsck 1.42.13 (17-May-2015)
# Warning: skipping journal recovery because doing a read-only filesystem check.
# /tmp/disk2: clean, 11/25688 files, 8896/102400 blocks
e2fsck -n /tmp/disk2.copy?offset=70000000
# e2fsck 1.42.13 (17-May-2015)
# /tmp/disk2.copy: clean, 11/25688 files, 8896/102400 blocks

Como podemos ver a montagem, o arquivo recupera o diário (e o sistema de arquivos é relatado como limpo por e2fsck), enquanto e2fsck -p gera um erro e não recupera o diário.

Se isso puder ser útil, aqui está a diferença entre as duas imagens de disco .

    
por Luca Citi 12.11.2016 / 18:20

0 respostas

Tags