Inicialização massivamente quebrada e sistema de partição

Question

A minha máquina tem um único disco rígido de 2 TB, com 3 partições:

• /dev/sda1 fat32 512MB
• /dev/sda2 ext2 244MB
• /dev/sda3 ext4 1.82TB

Meu 14.04 estava reclamando de 0 bytes em / boot, então eu entrei e fiz um sudo apt-get remove linux-headers-3.2.0.2* , pois já havia um linux-headers-3.2.0.30 disponível (eu queria remover tudo menos atual para liberar esse espaço e parar o sistema reclamando). Eu já descobri que esta é uma idéia terrível .

Meu sistema obviamente não inicializa, eu uso, a tela fica roxa e, em seguida, volta para o BIOS. Eu corri através de um passo muito abrangente por aqui , mas a situação permaneceu exatamente a mesma.

Eu decidi, dado que eu não estava vendo uma lista de opções do sistema operacional, que o GRUB pode precisar ser reinstalado, então eu corri através do Ubuntu Boot Repair mas como o meu ext4 é um LVM e eu não tinha rodado o Live Disc no modo UEFI, o programa Boot Repair me pediu para adicionar um sinalizador bios_grub ao / dev / sda3, o que fiz (que removeu o flag LVM). Eu continuei o reparo automático do Grub, que não funcionou. Na verdade, quando reiniciei o Live Disc, vi que o GParted não reconhecia mais o tipo de sistema de arquivos em /dev/sda3 . Eu redefinir o sinalizador para LVM e redefinir o sistema de arquivos para ext4 usando mkfs.ext4 /dev/sda3 .

Agora, quando eu montar /dev/sda3 , os únicos arquivos contidos nele serão lost+found . Além disso, eu costumava ter vgscan e vgchange -a y para montar a partição LVM, enquanto agora ela simplesmente monta com sudo mount /dev/sda3 /mnt , então presumo que o novo flag LVM não tenha restaurado o status LVM da partição. Eu realmente preciso dos meus dados de volta, e de preferência !, para o Ubuntu inicializar corretamente (embora eu suponha que eu possa reinstalar se tudo mais falhar, mas eu realmente preciso dos dados). O GParted ainda está relatando 29.41GB dessa partição conforme usado.

sudo parted -l retorna:

ubuntu@ubuntu:~$ sudo parted -l
Model: ATA WDC WD20EZRX-00D (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   fat32
 2      538MB   794MB   256MB   ext2
 3      794MB   2000GB  2000GB  ext4               lvm


Model: Generic STORAGE DEVICE (scsi)
Disk /dev/sdb: 2003MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      66.0kB  2002MB  2002MB  primary  fat16        boot

Imagem das minhas partições é mostrada aqui

Por favor ajude.

    

Answer 1

Você já lavou seu sistema; Espero que você tenha backups. Se não, eu tenho algumas sugestões de recuperação depois. Primeiro, porém, quero apontar seus erros para que você não os repita ...

% bl0ck_qu0te%

O pacote linux-headers (na verdade, linux-headers-3.13.0-45-generic ou algo semelhante) não contém arquivos em /boot ; ele contém arquivos de cabeçalho usados por programadores para escrever programas que interagem com o kernel. A maioria de seus arquivos vai na árvore de diretórios /usr/src . Um usuário comum pode não precisar deles, embora eles provavelmente sejam puxados por dependências. A questão é que excluir linux-headers provavelmente era inofensivo e não ajudaria a recuperar espaço em /boot .

O próprio kernel vem de um pacote chamado linux-image , não linux-headers . Se você removeu esse pacote (incluindo todas as versões dele; você pode ter dois ou mais kernels instalados de uma só vez), então o computador pararia de inicializar. Eu não sei de improviso se Boot Repair seria capaz de consertar isso. Reinstalar o GRUB seria inútil. Você precisaria inicializar um sistema de emergência e reinstalar o pacote linux-image . Você também pode precisar reconfigurar (mas não reinstalar) o GRUB.

% bl0ck_qu0te%

Este é seu primeiro erro muito sério. O " bios_grub flag" é um código do tipo de partição que diz ao GRUB que ele pode usar a partição para armazenar parte de si mesmo, sem passar por nenhum sistema de arquivos ou LVM na partição. Assim, depois de fazer essa alteração e reinstalar o GRUB, o GRUB substitui os primeiros setores do seu LVM. A maioria dos dados do LVM ainda estava intacta, e é possível que você tenha se recuperado neste ponto, embora possa ter sido difícil. Mas então ....

% bl0ck_qu0te%

Se permitir que o GRUB se escrevesse nos primeiros setores da partição LVM lançando os dados na lixeira, essa ação foi feita pelos trabalhadores do setor de limpeza removendo seu lixo. O utilitário mkfs (e todos os seus "ajudantes", como mkfs.ext4 ) não diz simplesmente ao Linux qual é o tipo de sistema de arquivos, como você parece pensar; ele grava novos dados do sistema de arquivos de baixo nível no disco. É como pintar uma folha de papel para que você possa reutilizá-la.

Sua melhor chance de recuperação neste momento é se você tiver bons backups. Se assim for, recomendo que você reinstale o Ubuntu do zero e restaure seus dados pessoais dos backups.

Se você não tem backups, ainda há uma chance de recuperar algo, mas será difícil - como ir ao lixo da cidade e vasculhar a lixeira para encontrar suas coisas. O procedimento é:

1. Faça um backup de baixo nível do disco, como em sudo dd if=/dev/sda of=/path/to/lots/of/disk/space/sda-backup.img . Você precisará de um segundo disco maior que o original, disponível em /path/to/lots/of/disk/space , no qual armazenar o backup. A questão disso é ter uma opção de recuperação no caso de você cometer mais erros, o que é muito provável neste ponto - algumas das ações a seguir podem piorar a situação, e não há como evitar isso.
2. Use gdisk para excluir as partições no disco original.
3. Use TestDisk para tentar localizar seu sistema de arquivos ext4 original e criar uma nova partição em torno dele. Note que, AFAIK, o TestDisk não sabe sobre o LVM, mas há uma boa chance de criar uma partição "bruta" (não-LVM) em torno do sistema de arquivos, desde que você não tenha expandido seu sistema de arquivos depois de criá-lo. Observe que o TestDisk provavelmente descobrirá o sistema de arquivos que você criou que substituiu o original, mas como você usou o LVM originalmente, o novo sistema de arquivos não começou no mesmo ponto que o original e as estruturas de dados críticas serão comparadas umas às outras. então o TestDisk pode ser capaz de encontrar o suficiente do sistema de arquivos original para acessá-lo.
4. Se o TestDisk foi bem-sucedido, execute fsck na partição resultante. As chances são que ele vai encontrar erros e você terá que ajudá-lo a recuperar. Muitos arquivos serão danificados. Eu ficaria chocado se você pudesse inicializar a partir desse sistema operacional, mas pode estar intacto o suficiente para recuperar pelo menos alguns de seus arquivos pessoais.
5. Se o TestDisk não for bem-sucedido, use PhotoRec para tentar recuperar arquivos individuais. Este será um processo doloroso, pois você precisará revisar cada arquivo para descobrir o que é.

É possível que o TestDisk ou fsck causem mais danos. Se você suspeitar que isso aconteceu, você pode restaurar seu backup.

Boa sorte com sua recuperação. Quando terminar, use o novo disco que você comprou para fazer o backup do sistema regularmente.