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).
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)
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
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 .