POP OS mensagem: Pouco espaço em disco em "Sistema de arquivos root"

Olá pessoal!
Estava usando o MAD LINUX, aliás deveria ser a versão do ubuntu studio, um sistema leve e sem complicações, resolvi instalar o pop os e a partir daí tive esse problema. O sistema da aviso que tem apenas 615 MB disponível, com duas opções 1-examinar e 2- ignorar.

Posterior a isso apareceu a tela de analise de disco.

Como podem ver o log tem um tamanho de 32,4 GB de tamanho. Quando abri o log no nautilus apareceu esta tela.

kern.log e syslog.1 estão enchendo o HD. Como solucionar isso focando na vida útil do hd? Terei que ficar o tempo todo apagando isso?
rodei os comandos abaixo para apagar.

#cat /dev/null > /var/log/kern.log
#cat /dev/null > /var/log/syslog.1

Alguém poderia me ajudar nisso, neste problema de registro desordenado? Muito grato.

1 Curtida

Você pode apagar os logs sem problema, mas seria interessante ver o que está gerando tantos logs assim.

2 Curtidas

Esse tipo de log é criado pelo kernel quando ocorrem certos evento, até a inicialização da máquina gera esses arquivos, em geral ele costuma ocupar menos de 1 mega, é provável que seja alguma configuração incorreta ou mesmo algum bug, existem formas de limitar o tamanho máximo de criação do arquivo, mais são soluções temporárias, se não quiser se preocupar com isso, a solução mais radical é simplesmente desabilitar a geração do LOG. (em meus testes isso não gerou consequências, mais fica o aviso)

Acesse: o arquivo rsyslog

sudo nano /etc/rsyslog.conf

Pesquise por ‘imklog’ e comente a linha que se parece com esta:
module(load=“imklog” permitnonkernelfacility=“on”)

deixando assim:

#module(load=“imklog” permitnonkernelfacility=“on”)

Esse log não será mais criado.

1 Curtida

Existe algum problema no computador, que está gerando saída de erro em loop no log.

  • Primeiro apague o syslog.1 pra não entupir o disco.
  • Depois monitore os logs e veja qual mensagem fica se repetindo: sudo journaclt -f
  • Feche o monitoramento com Ctrl+C.
  • Procure soluções para a mensagem de erro (google ou se não achar nada, manda aqui)
3 Curtidas

se vc n tem o hábito de “ver log” ou não sabe como fazê-lo - ou seja - s n tem utilidade pra sua pessoa, desabilite sua geração ou bote pra RAM, no fstab.

nunca me preocupei com log. se der algum problema, formato e instalo de novo, oq nunca m ocorreu.

1 Curtida

Penso da mesma forma.

Boa noite! O arquivo log que fica gigante são 4: kern.log, kern.log.1, syslog, syslog.1 . Efetuando a mudança da linha de comando não traria problema ao sistema?

O HD entupiu hoje, apaguei os logs. segue os novos arquivos gerados.

Link do syslog
https://drive.google.com/file/d/1YezTRH9-W7axhaSpW8osqAUaPIy-oiZK/view?usp=sharing

Link do kern.log
https://drive.google.com/file/d/1-PVOgzxF9Cc1VoC07O7A5L_WFEpLxjc4/view?usp=sharing

Pesquisando em alguns sites, vi uma solução. Pode-se determinar um tamanho específico do diretório e também determinar a rotação de logs. A solução foi feita no fedora.
Segue o link.

Diante de tudo isso, gostaria mesmo é que o sistema rodasse sem erros exacerbados como neste caso. Analisando o log, é melhor tentar arrumar, desligar a geração de log ou fazer a configuração do fedora do link acima?

Fiz o passo a passo que sugestionou. A maioria dos logs é da minha placa de vídeo Nvidia.
Uso um note MSI core i7 8750h com gtx1050.

Teoricamente não, mais o processo pode ser facilmente desfeito.

Decodificando o log:

pcieport 0000:00:1d.4: AER: Corrected error received: 0000:03:00.0
módulo do kernel pcieport (que controla a informação dos barramentos pci-express) corrigiu um erro no barramento 0000:00:1d.4 proveniente do dispositivo localizado no endereço 0000:03:00.0

alx 0000:03:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Módulo do kernel alx ( controlador de ethernet Qualcomm Atheros) está mandando uma mensagem sobre o dispositivo que está no endereço 0000:03:00.0. A mensagem é que houve um erro barramento PCI-express. Esse erro foi corrigido e é do tipo “camada física” (mas como geralmente a rede é onboard, somente um dano físico na placa mãe ou curto circuito interno nas trilhas poderia gerar algo terrível deste modo. Talvez seja indicação de erro físico mas na realidade seja um problema de driver inadequado)

alx 0000:03:00.0: device [1969:10a1] error status/mask=00000001/00002000
De novo o driver alx, dessa vez dando mais destalhes sobre o dispositivo, que é do fabricante 1969 (Qualcomm Atheros) ID 10a1 (QCA8171 Gigabit Ethernet). Erro 1, máscara 2000 (em hexadecimal)

alx 0000:03:00.0: [ 0] RxErr
Provavelmente a descrição do erro existente no driver: RxErr

Daí começa tudo de novo:
Jun 8 18:12:22 pop-os kernel: [82908.827918] pcieport 0000:00:1d.4: AER: Corrected error received: 0000:03:00.0

2 Curtidas

Como ter uns outros erros referente ao mesmo hardware, como BadDLLP e BadTLP, dá pra tentar essas soluções:

  • Habilite a opção “IOMMU” na BIOS.
  • adicionar a seguinte opção de kernel pci=nommconf que desabilita alguns recursos do barramento pci.
  • adicionar a seguinte opção de kernel pcie_aspm=off que desabilita o gerenciamento de energia no barramento pci-express. Pela documentação do kernel pode gerar travamento do computador.

Se vc está usando o computador no cabo de rede, faça uma verificação no cabo e tente colocam em outra porta do roteador. Talvez esse erro esteja associado com problemas na internet, lenta, perda de pacotes e desconexões aleatórias.

2 Curtidas

Dado que aparentemente já está definido que o problema tem a ver com a “placa” de rede, poderia tentar desabilitar a rede onboard (caso seja) e ver como se comporta. Se resolver é só colocar outra placa de rede.
Agora, como estava funcionando sem problema em outro sistema, outra alternativa é tentar trocar o driver dessa placa.

Atualizando: Desculpe, só vi agora que é um laptop. A ideia de colocar outra placa pode ser um pouco difícil. :stuck_out_tongue_winking_eye:

Pelos relatos resolvidos, colocar a opção do kernel foi o jeito…

2 Curtidas

No ubuntu já tive uma vez esse problema, no MADLINUX rodava liso como um mar sem ondas, no pop os está dando isso. Três duvidas me surgiu.
1 - Como poderia incluir esses dados que sugestionou, no kernel?
2 - Atualização do sistema de alguma forma poderia sobrescrever esta alteração que faremos no kernel?
3 - Questão de segurança do sistema é alterada?

Teria que ver o que está gerando o erro, mas vc pode limitar o tamanho dos logs se quiser

De uma olhada em log do journal e logrotate

1 Curtida

Eu tive uma experiência semelhante, onde o disco começou a ficar cheio devido aos logs, no meu caso foi devido ao VLC ficar com um vídeo aberto quando o eu suspendia o computador. Em uma suspensão encheu o disco de logs. Nesse caso a solução foi fechar o VLC quando suspendo ou não suspender.

Mas esse foi um caso que aconteceu comigo, não necessariamente é o seu problema. O ponto é: dê uma olhada nos logs e veja o que causa isso, como já detalhado em respostas anteriores. Se isso está ocorrendo, não é devido à operação normal. Caso o que causa esses logs não é necessariamente um problema, aí pode desabilitar os logs nas configurações do rsyslog, de acordo com a categoria que eles se encaixam.

Vou ler isso e tentar colocar em prática.

  1. Tem esse vídeo que vc pode ver pra adicionar provisoriamente a opção de kernel na inicialização do grub. Se funcionar vc deve adicionar como opção de inicialização no /etc/default/grub seguindo algum tutorial. Se for o systemd-boot eu não sei como fazer…
  1. A alteração é no grub dificilmente é sobrescrita em atualizações. No systemd-boot eu não sei.

  2. Pelo que li dessa opção vc vai perder algumas funcionalidades com relação à economia de energia… Fique atento à duração da bateria pra ser se é impactante (assumindo que alguma das opções do outro post resolveu o problema).

1 Curtida