Eu fragmento arquivos em /, e agora fico com o kernel panic, o que posso fazer?

Question

Eu deletei acidentalmente todos os arquivos em / , meu sistema não inicia mais. Pastas e links ainda lá, nada parece estar perdido. mas "kernel panic não sincronizando incapaz de montar o root fs" depois que o grub tentou iniciar o sistema.

Sistema totalmente criptografado xubuntu 12.04, criptografia bem, acessível usando resgate. Tentei várias coisas com o salvamento e instalei um novo sistema em outra partição para copiar arquivos apagados manualmente. mas não há arquivos adicionais lá. Talvez arquivos que só ocorrem em um sistema criptografado?

• Eu preciso de uma maneira de reparar meu sistema (arquivos ausentes?)

• E uma maneira de inicializar novamente, desde que eu tive que instalar o grub no MBR para o sistema na outra partição (não funcionou de outra maneira, a instalação / rescue / ubuntu se tornou ridícula).

Answer 1

Ok, se o que você diz nos comentários estiver correto, você usou shred * com o usuário root (a única maneira de fazer isso). Mas primeiro, vamos ler o manual:

% bl0ck_qu0te%

Então, o que você fez. Você simplesmente substituiu o conteúdo dos arquivos (não os arquivos propriamente ditos) pelo lixo:

braiam@bt:~/lab$ touch file1 file2 file3
braiam@bt:~/lab$ ls
file1  file2  file3
braiam@bt:~/lab$ cat *
braiam@bt:~/lab$ 
braiam@bt:~/lab$ shred *
braiam@bt:~/lab$ cat *
VXK��6z�z�-K� Eˎ�F��O�č��ؖɄw����Pw(R�����xd/���O��2����lD�y�0��8Gй�4Q�k�7��ݤ
## Actually there was more garbage here, but it would make this answer too long.

Sim, a última linha é o "conteúdo" dos arquivos uma vez vazios. É por isso que quando você verifica os arquivos, eles ainda estão lá, mas o conteúdo está uma bagunça.

Por sorte, o shred não pode abrir diretórios:

braiam@bt:~/lab$ mkdir dir
braiam@bt:~/lab$ mkdir dir1
braiam@bt:~/lab$ mkdir dir2
braiam@bt:~/lab$ ls 
dir  dir1  dir2  file1  file2  file3
braiam@bt:~/lab$ touch dir/file2
braiam@bt:~/lab$ touch dir1/file2
braiam@bt:~/lab$ touch dir2/file2
braiam@bt:~/lab$ shred *
shred: dir: failed to open for writing: Is a directory
shred: dir1: failed to open for writing: Is a directory
shred: dir2: failed to open for writing: Is a directory
braiam@bt:~/lab$ cat dir/file2 
braiam@bt:~/lab$ 

Portanto, tudo o que estava abaixo de /*/ é seguro. Isso nos deixa com a pergunta: o que exatamente você estragou?

$ ls -p / | grep -v /
0
initrd.img
vmlinuz

_{(Eu realmente não sei o que está fazendo esse arquivo chamado 0 lá, mas vamos ignorá-lo)}

Então você estragou o initrd.img que no meu caso está vinculado a initrd.img -> /boot/initrd.img-3.10-1-686-pae e o vmlinuz que no meu caso está vinculado a vmlinuz -> boot/vmlinuz-3.10-1-686-pae . Um dpkg -S nos dirá quais pacotes têm esses arquivos:

$ dpkg -S boot/vmlinuz-3.10-1-686-pae
linux-image-3.10-1-686-pae: /boot/vmlinuz-3.10-1-686-pae
$ dpkg -S initrd.img-3.10-1-686-pae
dpkg-query: no path found matching pattern *initrd.img-3.10-1-686-pae*

Como você pode ver, o arquivo vmlinuz * está dentro do linux-image-3.10-1-686-pae , então uma simples reinstalação em um ambiente com chroot deve ser feita. Para o initrd.img, as coisas são complicadas e precisarão do uso de mkinitramfs ou mais especificamente update-initramfs :

$ update-initramfs -h
Usage: /usr/sbin/update-initramfs [OPTION]...

Options:
 -k [version]   Specify kernel version or 'all'
 -c     Create a new initramfs
 -u     Update an existing initramfs
 -d     Remove an existing initramfs
 -t     Take over a custom initramfs with this one
 -b     Set alternate boot directory
 -v     Be verbose
 -h     This message

Ao chamar update-initramfs no ambiente chrooted, é provável que você recupere seu sistema novamente.