Como corrigir “sulogin: não pode ler / dev / tty7: Operação não permitida” na inicialização - 17.10 drive externo

Question

Eu instalei recentemente o Lubuntu 17.10 em um disco rígido externo novo e ele está me dando problemas regularmente durante a inicialização. Eu recebo a mensagem do título.

Se eu inicializar no modo de recuperação, além de os drivers de vídeo não serem carregados, tudo parece bem.

Eu carreguei um CD ao vivo e executei a opção "Check Disk". Isso corrigirá o problema temporariamente, mas uma ou duas inicializações depois, o problema invariavelmente recomeça.

Ao instalar o sistema operacional, é como eu formatei a unidade, tomando emprestado das recomendações que encontrei na Web: link

Eu reformatei o drive e comecei do zero duas vezes agora e, no caso de ser algo que vale a pena mencionar, notei a última vez que funcionou por vários dias e várias inicializações, mas logo após instalar o postgresql 9.6 e configurar um par servidores, foi quando os problemas de inicialização começaram a aparecer. Pode ser nada mais do que uma coincidência ...

Algum apontador? Coisas que posso tentar solucionar? Eu li outros falando sobre editar o / etc / fstab, mas eu ainda sou relativamente novo no Linux como um SO e não sei o que estou procurando lá.

UPDATE: Outras mensagens de erro estão começando a aparecer . Incluindo estas saídas de "journalctl -xb":

• Não é possível encontrar o TOCBLOCK, o banco de dados pode estar corrompido
• Nenhuma página do modo de armazenamento em cache foi encontrada
• Intervalo do intervalo SystemID conflita com Opregion
• fsck falhou com o código de erro 4
• Dependência falhou no sistema de arquivos local

Apenas pensando em voz alta aqui, mas poderia ter alguma coisa a ver com o fato de que estou conectando a unidade em vários computadores? Eu preciso que seja estável para o meu laptop, enquanto eu viajo, essa é a razão pela qual eu optei por um drive externo em primeiro lugar.

Obrigado antecipadamente por qualquer ajuda que você possa oferecer! Deixe-me saber se você gostaria de postar mais alguma informação!

    

Answer 1

ATUALIZAÇÃO 20180327: Recentemente encontrei um comando bastante esotérico que, nas últimas duas semanas, corrigiu meus problemas de inicialização. Aqui está o que eu fiz ...

Mantenha pressionado o ALT + SysRq (no meu laptop, o SysRq é uma tecla de função no END) e, enquanto segura as teclas, LENTAMENTE - aguarde um segundo ou dois entre cada tecla - digite REISU B. fazer várias coisas, incluindo reiniciar o computador. E voila! Eu tenho estado livre de problemas nas últimas duas semanas.

Então, o que exatamente isso faz?

• R: alterna o teclado do modo bruto para o modo XLATE
• E: Envie o sinal SIGTERM para todos os processos, exceto init
• I: Envie o sinal SIGKILL para todos os processos, exceto o init
• S: Sincronize todos os sistemas de arquivos montados
• U: Remontar todos os sistemas de arquivos montados no modo somente leitura
• B: Reinicie imediatamente o sistema sem desmontar partições ou sincronizar. Se você quiser desligar o computador, digite O em seu lugar.

UPDATE 20171120: Parece que há um problema recorrente com o / dev / sdb3, em que os inodes se tornam órfãos. Sempre que o sistema inicializa no Modo de Manutenção, a execução do seguinte corrige consistentemente o problema:

$ umount /dev/sdb3 # as a precaution, sdb3 is usually not mounted yet
$ fsck -y /dev/sdb3

Isso normalmente retorna um aviso dizendo que "blocos livres contam errado ..." e depois "inodes gratuitos contam errado ..." seguido de uma correção.

Por que o sistema regularmente faz isso, o júri ainda está fora. Mas, enquanto isso, isso conserta o sistema e traz tudo de volta à ordem de trabalho.

ATUALIZAÇÃO 20171113: Welp ... Acontece que esta resposta foi uma medida provisória temporária na melhor das hipóteses ... O sistema irá arrancar várias vezes seguidas sem nenhum problema. Mas então, aparentemente do nada, ele começará a entrar no modo de manutenção. A única "correção", então, é inicializar no modo de recuperação e executar um disco de verificação. E se isso não corrigir a inicialização padrão, carregue um CD ao vivo e execute a verificação completa do fsck.

O fato de o sistema funcionar bem no modo de recuperação me deixou confiante de que o disco não estava corrompido. Além disso, como os drivers de vídeo não estão totalmente carregados no modo de recuperação, isso me fez suspeitar que tinha algo a ver com o chip AMD Radeon do meu laptop.

Isso me levou a descobrir o seguinte comando:

$ unbuntu-drivers devices

Este comando lista os pacotes disponíveis que correspondem ao hardware do sistema. No meu caso, isso listou "amd64-microcode". Depois de instalar esse pacote, eu não entrei em mais problemas de inicialização (knock on wood). Repeti o mesmo processo quando a unidade está conectada à minha área de trabalho principal, para que a unidade esteja totalmente pronta para uso em ambos os ambientes.