O primeiro erro que você relatou:
ata1:00: status: { DRDY ERR }
ata1.00: error {UNC }
ata1:00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1:00: BMDMA stat 0x25
ata1:00: failed command: READ DMA
diz que um comando READ DMA ATA para um disco na porta ATA 1 falhou (status inclui ERR para erro ). Essa porta é provavelmente o disco rígido, e o erro aponta para a unidade com problemas. A parte DMA provavelmente pode ser ignorada; O DMA é Direct Memory Access , que é o modo de transferência dominante nos dias de hoje, e se você estava tendo problemas de RAM ou barramento de RAM Se você estivesse batendo em algo assim repetidamente, provavelmente veria mais erros se o sistema fosse capaz de funcionar.
O segundo erro:
end_request: critical target error, dev sda, sector 32839936
EXT4_fs error: (device sda5): ext4_find_entry:935: inode #393217: comm init: reading directory lblock 0
INIT: No inittab file found
diz que há algum problema em / dev / sda, setor 32839936, que com setores de 512 bytes nos coloca fisicamente no final da partição / dev / sda5, o que resulta em device sda5 conforme relatado pelo sistema de arquivos motorista. O erro relatado por init junto com os detalhes do erro do driver do sistema de arquivos aponta para um problema com o sistema de arquivos, fazendo com que o / etc / inittab fique indisponível ou (menos provável) ilegível. Isso significaria que o diretório raiz, o diretório / etc ou a entrada do arquivo / etc / inittab estão de algum modo envolvidos na corrupção. Dado o número de inode, eu tomaria uma iniciativa em / etc / inittab sendo especificamente o culpado, até que se prove o contrário.
Você escreve (minha ênfase):
Suspecting a HDD crash, I took it out and used in another PC as an external USB HDD drive and I was able to mount & see all partitions and files within. So I assume Disc is OK.
Eu diria que sua suposição é infundada. O disco está obviamente tendo algum problema; com alguma sorte, será fácil de corrigir.
A primeira coisa que eu faria na sua situação é atualizar meu backup de tudo o que está nesse disco. Certifique-se de não substituir ou excluir nada do seu backup mais recente, pois certamente há a possibilidade de você precisar dele. Talvez a melhor opção seja fazer um novo backup em um novo (ou pelo menos não usado anteriormente para seus próprios backups) unidade de tudo o que você é capaz de acessar. Espere alguns erros de E / S na fonte ao fazer essa cópia.
Segunda vem tentando recuperar. Com alguma sorte, dados os erros, este é um problema de setor único ou de poucos setores que causou uma pequena quantidade de corrupção no sistema de arquivos, caso em que e2fsck deve ser capaz de reparar a maior parte o dano. Alguns de seus arquivos provavelmente desapareceram, mas com alguma sorte, você pode encontrá-los em / lost + found sob a raiz de montagem do sistema de arquivos (por exemplo / data / lost + found se você montar / dev / sda5 em / dados) depois de ter e2fsck fazer o que puder. Caso contrário, faça uma comparação com o backup mais recente de antes dos problemas iniciados e restaure os arquivos relevantes do backup. (Eu mencionei backups são úteis se coisas ruins acontecerem, como inevitavelmente acontecem?)
Terceiro surge a questão de saber se você pode confiar na unidade para uso futuro. Alguns setores defeituosos não precisam ser catastróficos do ponto de vista da unidade, mas as unidades rotacionais de aproximadamente 100 GB praticamente não podem ser usadas hoje em dia na maioria dos fatores de forma, o que indica que essa é uma unidade relativamente antiga. Pessoalmente, eu provavelmente só aceitaria que a unidade sobreviveu a sua vida útil neste momento e obter uma substituição, mas novamente eu estou bastante paranóico quando se trata de meus dados; sua milhagem pode variar. Você terá que pesar o custo de uma unidade de substituição contra o risco de falha total da unidade e subsequente perda total de todos os dados na unidade.