m4iir1c10
(usa Arch Linux)
Enviado em 20/07/2012 - 03:29h
Isso e algo que nao da para evitar, mais cedo ou mais tarde acabamos nos deparando com esse tipo de cenario o qual voce se encontra, depois de um boot forcado o sistema nao volta, isso porque algo aconteceu com o seu sistema de arquivos enquanto voce forcou o reboot.
Mais nao se preocupe nao foi sua culpa :)
Vamos resolver esse problema forcando um analise do seu HD para procurar onde aconteceu o erro se aconteceu relamente.
Como o nosso amigo ja tinha mensionado uma pratica 100% recomendavel e separar o /home do sistema porque no evento disso acontecer e um arquivo do Linux ser corrompido voce pode reverter a situacao com uma nova instalacao mantendo os seus arquivos.
Caso isso aconteca na particao /home voce pode perder um dos seus arquivos no qual voce estaria trabalhando no momento da reiniciacao forcada.
Bom chega de lero-lero, primeiro ao parar a iniciacao naquela tela preta digite:
init 1
depois desmonte a particao que voce quer analizar, digamos que suas particoes esteja separadas e voce quer escanear a /home e essa particao se encontra em /dev/sda2
umount /home ou
umount /dev/sda2
voce pode rodar o comando para checar sua particao assim:
fsck /dev/sda2
# caso o programa peca para voce identificar o sistema de arquivos voce pode colocar -t e o sistema de arquivos que voce usa, por exemplo no caso de um sistema de arquivos ext3
fsck -t ext3 /dev/sda2
Desta maneira se voce for fanatico por detalhes e quer saber cada arquivo que foi modificado, caso voce nao queira saber quais arquivos foram modificados so quer o negocio funcionando digite:
fsck -y /dev/sda2
Isso vai evitar o programa de te perguntar se voce quer mover o arquivo corrompido ou nao, apos o processo voce pode reiniciar o computador com o comando:
reboot
Desta vez se o sistema nao foi comprometido voce vai reiniciar normalmente, para ver qual foram os arquivos danificados olhe na pasta lost&found