Como resolver o modo de emergência e possível bloqueio de SSD?

[Gustavo82]

Olá, pessoal!

Estou precisando de ajuda com meu SSD MX500 Crucial.
Comecei a usá-lo dia 31/07, em GPT, com o Windows10 e Manjaro Gnome em dual boot e uso o HD antigo do notebook em um adaptador caddy para armazenamento de dados.

Estava usando o Manjaro no dia 06/09, e após fazer a instalação do VLC (flatpack), Kdenlive (repositório) e de uma atualização do sistema (não me recordo o nome), meu notebook parou de acessar o Manjaro, acusando um erro. No entanto, o Windows10 funciona normalmente após selecioná-lo no GRUB (tenho usado ele desde então). Segue abaixo imagem do erro apresentado:

Figura 1. Erro no SSD após atualização do sistema.

Consegui usar o comando journalctl -xb descrito na imagem a cima e o resultado foi uma lista enorme que chegava até a linha 1564. Essas duas fotos abaixo são de alguns trechos:

Figura 2. Resultado do comando journalctl -xb linha 1-47/1564.

Figura 3. Resultado do comando journalctl -xb linha 1256-1302/1564.

Falei com @Rodrigo_Chile e ele me sugeriu fazer a formatação do Manjaro Gnome.
Fiz a formatação com a nova ISO do sistema (Pahvo 21.1.2), mas não funcionou. Então tentei com a anterior, Pahvo 21.1 (que era justamente a que eu estava usando antes de dar o problema), mas também não deu certo. Em ambos os casos, após a escolha do Manjaro no GRUB, meu notebook apresentava a mesma resposta da Fig. 1.

Portanto, realizei a formatação completa do SSD, apagando todas suas partições e criando uma nova tabela GPT, onde reinstalei o Windows10 e depois o Manjaro Gnome em btrfs, mas o erro da Fig. 1 persistiu.

Assim, resolvi apagar a partição do Manjaro e dividí-la em duas ext4. Em uma instalei o Xubuntu e na outra o RegataOS para verificar se o problema poderia ser o ManjaroGnome, mas infelizmente, o erro da Fig. 1 ainda existe quando escolho qualquer um dos sistemas no GRUB, exceto o Windows 10, que está funcionando normalmente.

Pelo modo live do Xubuntu, tentei utilizar o comando fsck para verificar quaisquer problemas que pudessem existir, mas não tive nada conclusivo.

Figura 4. Verificando partição com o comando fsck.

Conversando com @Rodrigo_Chile, ele me indicou usar a live do Manjaro para fazer o teste SMART pelo Gnome Disks no SSD e os resultados estão nas imagens abaixo:

Figura 5. Resultado do teste SMART Short.

Figura 6. Resultado do teste SMART Extend.

O @Rodrigo_Chile me disse que era muito estranho o SSD ter apenas 9 dias e já ter dois processos em pre-fail, apesar da avaliação geral estar como OK e mesmo assim o problema da Fig. 1 ainda existe.

Informações adicionais: durante as formatações, a BIOS sempre esteve com o secure boot desativado e o modo de formatação é em EFI/Boot.

Laptop Acer Aspire E1-571-6601
Intel® Core™ i3-3110M CPU 2.40GHz
Intel® HD Graphics 4000 (IVB GT2)
RAM DDR3L 12 Gb 1600MHz

Infelizmente, não conseguimos resolver este enigma e por isso, peço auxílio a comunidade do Diolinux Plus!

Obrigado pela atenção e apoio!

Gustavo

[anon76731478]

já experimentou outra distro?

[Gustavo82]

Olá, @anon76731478!

Depois que tive o problema usando o Manjaro (Gnome), testei o Xubuntu e o RegataOS para ver se o problema era resolvido, mas infelizmente não deu certo. Quando entro em qualquer um dos sistemas, volto aquela tela de modo de emergência da figura 1 da minha primeira postagem. Exceto o Windows10 que segue funcionando.

[RuKsu]

A formatação que você fez foi a que 0 todo o armazenamento? Talvez se formatar o SSD com o comando abaixo, possa ajudar a resolver.
shred -v -n1 -z /dev/...
Oque este comando faz é 0 todo o SSD/HDD, armazenamento, ou a partição escolhida deixando ele sem ter como recuperar nada. As vezes mesmo depois da formatação comum o Grub pode estar “enxergando” coisas que ele não deveria.
Para descobrir o /dev pode ser usado o comando:
fdisk -l
Depois disso tenta instalar os Sistemas denovo para ver se resolveria.

Só um cuidado com este método é que se o seu ssd for OEM por exemplo, ou seja, o computador for comprado de alguma marca do tipo, Dell, Lenovo, HP, Asus, ele poderá ter “partições secretas” especiais que as empresas instalam para ajudar na manutenção do Windows. Este método irá destruir estas partições.

[anon76731478]

teria como testar esse ssd em outro computador?

[Gustavo82]

Olá, pessoal!
Irei testar todas as sugestões ao longo da semana e volto com os resultados.

Muito obrigado!

[romulopb]

Você deveria ter verificado o journald novamente para ver se ainda é um problema de inodes orfãos na partição /dev/sdb2. Essa partição é seu /, /home, etc? usar lsblk vai nos ajudar a ter uma ideia do seu particionamento. Eu acho que ficar reinstalando sistemas não vai resolver, você vai ter de fazer um backup de /dev/sdb2 rodar o sfsck manualmente na mesma para recuperar esses erros ou simplesmente formatar essa partição.

[Lisandro]

@Gustavo82

Portanto, realizei a formatação completa do SSD, apagando todas suas partições e criando uma nova tabela GPT, onde reinstalei o Windows10 e depois o Manjaro Gnome em btrfs, mas o erro da Fig. 1 persistiu.

Gustavo, isso me intrigou uma vez. Onde estavam as informações se eu tinha formatado tudo. O erro não era o mesmo (após instalar n distros para teste, não conseguia instalar nenhuma nova), mas eu resolvi com o VisualBcd (www.boyans.net), removendo todas as entradas das distros anteriores. Não sei se vai ajudar, pois como disse, o problema no meu SSD era outro, mas se o teu Windows estiver funcionando, talvez valha a pena testar ou, pelo menos, limpar a BCD.

Eu tive uma falência de SSD depois de uma semana de uso, ele entrou no modo somente-leitura. Tive de recorrer à garantia e me trocaram o SSD.

[romulopb]

Gente… Pelo que deu para entender no journald dele é o dispositivo >>> sdb <<< com inodes ofãos, especificamente sdb2. Infelizmente ele não colocou a organização das partições mas ao que da a entender o problema não é o SSD se esse for sda.

Para mim cheira a alguma partição secundária atrelada ao boot sem opção nofail, esse tipo de partição automontada junto com o sistema, mesmo que não seja algo importante como /boot, / ou /home, se der algum problema, tranca o boot antes de chegar no multi-user.targete costuma jogar o usuário em um modo emergência.

[Gustavo82]

Boa tarde!

Para completar as informações, este é o particionamento do meu SSD:

1 - Do sda1 ao sda5 são as partições que o Windows criou;
2 - Em sda6 está o / de RegataOS;
3 - Em sda7 está o / de Xubuntu.

O sdb é o meu HD, onde uso a /home separado:

[romulopb]

Pois é, o seu problema é exatamente essa partição /home…

[Gustavo82]

Então bastaria apenas deletar a partição ext4 do HD e criar uma nova pelo Gparted?
Com a posterior formatação do / de uma das distribuições no SSD?

[romulopb]

Para de formatar seu SSD rapaz kkk tenta fazer um FSCK manual nessa partição /home, se você tem coisas que não quer perder na sua /home , faça backup, FSCK é sempre um risco para a partição.

 fsck -cy /dev/sdb2

[Gustavo82]

@romulopb

fsck -cy /dev/sdb2

Combinado, irei tentar e volto com novidades!

[KaMyKaSii]

Eu também tinha problemas do Linux Mint cair nessa tela de recuperação. Acontece que comprei meu notebook já usado e o ssd dele já está morrendo, o que leva a corrupção de alguns dados. Pra resolver temporariamente, eu sempre tinha que fazer boot na live do Mint e rodar sudo fsck /caminhodaparticao -y tanto para a partição raiz quanto home. Isso quando eu utilizava essas partições com o sistema de arquivos EXT4. Ao trocar para o XFS, nunca mais fiquei travado na tela de recuperação porque pelo que vi o XFS tem um sistema de recuperação próprio que é ativado em todo boot. Mas isso não significa que o problema de fato tenha sido corrigido, de vez em quando alguns dos meus arquivos se tornam ilegíveis, só será solucionado quando eu comprar um armazenamento novo.

[Gustavo82]

Olá, pessoal!

Estou realizando o teste que o amigo @romulopb recomendou, ainda não terminou e vou atualizando esta mensagem conforme for acabando:

Ele está parado nesta tela, o que eu preciso fazer agora?

[romulopb]

Humm acho que é uma boa ideia dar uma olhada nos dados SMART desse HDD. De qualquer forma, se informando no mais de 2 vezes, provavelmente o FSCK não vai conseguir resolver esse bloco e então será melhor ignorar com yes.

[swatquest]

Infelizmente o manjaro tem este problema.

Acho que o erro é devido um limpador de kernel do manjaro que de vez em quando apaga arquivos errado.

Ao aparecer a tela do erro para acessar como root.

Coloque a senha root e instale de novo o kernel.

pacman -S linux-nome

E reinicie e veja se entra.

Se funcionar

Depois vejo qual o serviço faz está bagunça e adiciono aqui.

[romulopb]

Outra questão, seu SSD está normal os dados SMART são confusos de interpretar mesmo, mas o tipo pré-falha só indica falha se o normalizado estiver se aproximando, igual ou menor que o limite (threshold). Toda lista de atributos SMART tem atributos do tipo pré-falha e os teus a princípio estão maximizados em 100.

Eu acho que na verdade você está perdendo seu HDD, só olhando os dados SMART do HDD (sdb, não do sda) para ter certeza, mas FSCK não conseguir ler um bloco é um mal sinal bem forte de existência de badblocks já.

[Gustavo82]

Olá, pessoal!

Antes do teste SMART do HD:

Não consegui realizar, o que pode ser?